memoire utilisée par les variables ?

Version imprimable

04/09/2009, 11h52
Zwiter

memoire utilisée par les variables ?

Bonjour,
J'ai un script qui utilise pas mal de mémoire (>10Go), et je voudrais connaitre la part de chaque variable (hash, et objet) à une certaine position du script.
Sauriez vous comment proceder ?
Z.
04/09/2009, 11h54
djibril

Devel::Size
04/09/2009, 12h32
Zwiter

J'obtiens un 'out of memory!' avec ce code :

Code:

print total_size($NanoAlign->{_PROBES_MAPPED}), "\n";

Sachant que NanoAlign est un objet, et que $NanoAlign->{_PROBES_MAPPED} est un énorme hash.

Est ce lié a cet aspect de Devel::Size ?

Citation:

Envoyé par CPAN

DANGERS

Devel::Size, because of the way it works, can consume a considerable amount of memory as it runs. It will use five pointers, two integers, and two bytes worth of storage, plus potential alignment and bucket overhead, per thing it looks at. This memory is released at the end, but it may fragment your free pool, and will definitely expand your process' memory footprint.

Precision niveau mémoire : mon script semble utiliser au max env 11go de mémoire (il dure longtemps, alors je ne peut pas dire s'il yn a un pique a un moment), et la becane dispose jusqu'a 32Go, mais en général environ 25Go sont libres.

Z.
04/09/2009, 12h35
djibril

possible. Essaye de tester d'autres variables. Et d'ailleurs, t'as pas moyen de faire autrement ? Car un script qui consomme 10 Go de mémoire, ça craint un peu non !!!
04/09/2009, 12h50
iblis

C'est presque le genre de situation de débugage où il faut avoir un Perl compilé avec DEBUGGING_MSTATS ou mieux avec DDEBUGGING sous la main. Tu peux alors utiliser mstat() avec Devel::Peek.
04/09/2009, 13h35
Zwiter

non, j'ai plus ou moins le choix. En tres gros, je parse un fichier de 1.4go. Mais par la suite, ce fichier pourra être encore plus gros.

Mais je voudrais connaitre les max que j'atteinds, et surtout dans quelles conditions.

J'ai jamais utiliser le debugger. Je vais creuser dans cette voie.

Z.
04/09/2009, 13h49
djibril

La taille du fichier a parser n'est pas le souci, mais la façon dont tu t'y prends ! Peux t on en savoir plus ?

Pas de soucis !
Pour remettre ceci dans le contexte. Ce script a été developper pour un projet européen. Ayant de la ressource informatique, nous n'avons pas chercher a optimiser cette application.
Actuellement, nous reflechissons à generaliser ces scripts afin de valoriser ce travail.

Voici le code brute de décoffrage :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
sub parse_mapping {
	my $this = shift;
	my $handle = $this->_open_file($this->{SEQMAP_FILE});
	my $i = 0;
 
	while ( my $line = $this->_next_line($handle) ) {
		$i++;
 
		my @temp = split("\t", $line);
 
		my @miss;
		my $mm = $temp[5];
		my $oligo = $temp[4];
		my $strand;
		if ($temp[6] eq '+') {
			$strand = 1;
			}
		else {
			$strand = 0;
			}
 
#insert into result hash
		$this->{_PROBES_MAPPED}{$oligo}{$mm}{$temp[0]}{$temp[1]}{$strand} = 1;
	}
	close $handle;
	return $i
}

Et voici un extrait du fichier à parser (actuellement : 20530675 lignes, pour 1.4G) :

Code:

1
2
3
4
5
6
7
8
9
10
trans_id        trans_coord     target_seq      probe_id        probe_seq       num_mismatch    strand
M73258_unc_unc  1       TATGTATGTTGCACTGTCCC    47391   TGTGTGTGTTGCAATGTCCC    3       +
M73258_unc_unc  1       TATGTATGTTGCACTGTCCC    147689  TATGTGTGCTGCCATGTCCC    4       +
M73258_unc_unc  1       TATGTATGTTGCACTGTCCC    198381  TATGTATGTTGCACTGTCCC    0       +
M73258_unc_unc  1       TATGTATGTTGCACTGTCCC    350633  TATGTGTGTTGCAGTGTCCC    2       +
M73258_unc_unc  1       TATGTATGTTGCACTGTCCC    376085  TATATATGTTGCAGTGTCCC    2       +
M73258_unc_unc  1       TATGTATGTTGCACTGTCCC    609890  TATATATGTTGCAATGTCCC    2       +
M73258_unc_unc  1       TATGTATGTTGCACTGTCCC    680106  TATATATGTTGCACTGTCCC    1       +
M73258_unc_unc  1       TATGTATGTTGCACTGTCCC    693815  TATGTGTGTTGCACTATTCC    3       +
M73258_unc_unc  1       TATGTATGTTGCACTGTCCC    718854  TATGTGTGCTGCAATGTCCC    3       +

Ces données sont par la suite insérées dans une base de donnée (certainement SQLite pour être portable sur tous les environnements).

Si mes recherches d'optimisations sont infructueuses, j'envisage de traiter séquentiellement ce fichier.
Le souci est que certains cas particuliers pourront toujours aboutir à une occupation importante de la mémoire, que je voudrais tester.
Z.

04/09/2009, 15h38
Zwiter

Je vais essayer d'optimiser mon hash sur le plan de l'ordre des clés.
Certaines ont beaucoup moins d'occurences que d'autres. Je pense qu'il est donc plus interessant d'avoir les clés les moins variables à la base du hash, et de terminer par les plus variables.

QU'en pensez vous ?

Z.
04/09/2009, 15h59
djibril

Concrètement, tu fais quoi sur ce fichier ? Tu le mets entièrement en mémoire ?
07/09/2009, 09h29
Zwiter

Oui, je mets chaque ligne en mémoire dans un hash, pour traitement.

Mes tentatives pour optimiser le tableaux n'ont mener a rien (je m'en doutais)...
Je vais donc essayer de decouper intelligement mon fichier. Ca aidera dans beaucoups de cas, mais certains pourront tjrs poser probleme.

Z.