Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Shop Recherche
1728 connectés 

  FORUM HardWare.fr
  Programmation
  Perl

  [perl] sbrk échoue, problème de consommation mémoire excessive

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[perl] sbrk échoue, problème de consommation mémoire excessive

n°529295
frenchkiss
Posté le 02-10-2003 à 14:53:15  profilanswer
 

bonjour,
 
voila sans perl et sans reproche je tape la main dans mon script
des tonnes de lines pour un prog de test de non regression.
 
test cases test suites  dans tous les sens
 
 
des new partout ( je fais normallement du C pousse-pousse alors j aime bien l'OO qiand je peux)
 
un premier test avec qqs fichiers de test , nikel
 
puis test un peu plus mouse avec 1000 test case repartis a peu pres equitablement en bloc de 20 test suites et..
 
 PAF , the claque.
 
 
<b>out of memory during request un sbrk() is 1017584044 </b>
 
alors la je tape sbrk sous yahoo (mon man a moi) et re claque,  
ca fait trop longtemps que j ai pas eu de cours de compil et je suis pas sur de tout piger.
 
heureusement vous etes la..
alors? une idee


Message édité par frenchkiss le 02-10-2003 à 15:20:38
mood
Publicité
Posté le 02-10-2003 à 14:53:15  profilanswer
 

n°529300
pospos
Posté le 02-10-2003 à 15:02:52  profilanswer
 

Quelle version de Perl utilise tu?
Esque tu utilise des modules avec du XS?
 
Esque tu fait des choses.... etranges?
 
En gros il fait koi ton bout de code qui plante (si tu a pu l'isoler) ?

n°529310
frenchkiss
Posté le 02-10-2003 à 15:12:32  profilanswer
 

perl 5.6.1
 
des choses etranges? ben le prog est assez simple
un objet pour gerer les test suites
un test suite etant composee de sous test suite et de test cases
 
un run sur cet objet provocant un run de ses sous suites et de tous ces cases.
 
un mecanisme de reporting ( et a monn avis c'est la que ca merdouille) dump ensuite les resultat (passed or failed ) en format hacheteumeuleu .
 
je teste en fait le resultat d'une requete sur un serveur en dumpant sous forme xml le resultat ( via un schema genere automaitquement  d apres l idl )
 
..tiens en le disant je me rends compte  que finnalement oui je fais des choses bizarres.
 
sinon ma question pourrait etre ,:
 
y a til qqch a faire lorsque l'on sais que l on doit garder des gros objets en memoire avec perl ?  
un truc du style sbrk(100000000000000) :) ?
 

n°529316
pospos
Posté le 02-10-2003 à 15:17:03  profilanswer
 

Il y a pas mal de solution pour reduire al conso memoire, notament au niveau serialisation
mais tout dépend de tes sturctures, c'est difficile à dire comme ca...
Si tu ne fait pas d'heritage tu peut regarder du coté de... putain je me souviens plus du nom du module est search.cpan est en panne...
 
enfin ya des modules qui permettent une meilleur gestion memoire en OO. deja tu peux regarder du coté du pragma "filds" (je ne sais pas quelle version il y avait dans perl 5.6...)
 
Mais il faudrait que je retrouve le nom de l'autre module, il est terrible si tu a un tres tres grand nombre d'objets à traiter
 
la probleme vient du nombre d'objet ou de la taille de chaque objet à ton avis?
 
tu utilise un prog externe d'ou pourrait venir l'erreur? le serveur lui il est content (question inutile, dont je ne vois pas le sens...) ?

n°529336
frenchkiss
Posté le 02-10-2003 à 15:30:32  profilanswer
 

il y a de l heritage, j'herite en fait de clase testcase et test suite existantte . c'est grace a cette heritage que le mecaisme de reporting peut etre utilise ( une methode permet de reporter une failure , et donc ce test,suite ou case, sais kil a plante , bien sur ondit pourquoi dans la methode ..bref je ne me tends pas trop)
 
bon je vais aller voir le mec qui a ecrit les classes de base et le pseudo framework de test.
 
mince moi qui penser me liberer de cette tache de test assez vite ;)
 
 
pour le dilemme taille / nombre , ben c est sur que si un objet occupait moins de place j aurai ptet pas le probleme , mais comme c est incompressible (je veux dire par la que j ai pas d autre choix que d utiliser ce mecanisme , et donc ce type de classe) , dans mon cas c est le nombre qui fait tout deborder.
bon evidement je pourrait tricher et modifier la logique en disant qu'il n y a non plus 1 seul test suite de base mais plusieurs ( et donc provoquer la generation html plus vite)
 
mais ca serait un peu de la bidouille , puisqu il faudrai que je rajoute une couche qui , connaissant tous les tests suite racine, me dise si mon test 'general' (l ancien test suite racine unique) a reussi..  sachant que ca normalement c'est pas a moi de le faire car ce mecanisme est integre au test suite..ben j vous plaint a lire ces details..  
 
 
le serveur lui , comme tu t en doutes , se moque que le client fasse des conneries avec ce qu'il renvoie ( a la mlimite c'est meme pas sur la meme machine..)  
 
<citation> bon pendant ce temps la je suis pas au bistro </citation>  
 
 
bon je vais regarder cette histoire de pragma gedon

n°529347
pospos
Posté le 02-10-2003 à 15:40:27  profilanswer
 

bon courage...

n°529363
frenchkiss
Posté le 02-10-2003 à 15:54:54  profilanswer
 

merci !
 
ps a taz: je preferer mon titre de subject ;)

n°529369
Taz
bisounours-codeur
Posté le 02-10-2003 à 16:02:49  profilanswer
 

frenchkiss a écrit :

merci !
 
ps a taz: je preferer mon titre de subject ;)

et moi je n'éprouve pas le besoin de faire l'intéréssant au point de devoir écrire « subject »    [:spamafote]

n°529387
frenchkiss
Posté le 02-10-2003 à 16:24:57  profilanswer
 

les bras m'en tombent ..taz ta remarque me sidere (tu peux regarder dans le dico c est francais..).
on parle de pragma , de framework et d'object avec des out of memory et toi tu trouves ca carrement irreel d'employer le mot subject.. ben tu dois en corriger des "topics"  ( =~ sujet )  
 
bon sinon j ai un expert PERL  (Practical Extraction and Reporting Language ...) aussi auteur de l outil de reporting qui va venir me filer un coup de main
 
je vous poste la reponse ( the answer)
 
 
 
 
 

n°529388
Taz
bisounours-codeur
Posté le 02-10-2003 à 16:26:17  profilanswer
 

:pfff:

mood
Publicité
Posté le 02-10-2003 à 16:26:17  profilanswer
 

n°529396
nraynaud
lol
Posté le 02-10-2003 à 16:30:59  profilanswer
 

frenchkiss a écrit :


<b>out of memory during request un sbrk() is 1017584044 </b>

Félicitations, c'est la première fois de ma vie que je vois un sbrk échouer. T'as dû y aller très très fort quand même.
 
arriver à mapper tout la mémoire physique + tout le swap dans un seul process, c'est très fort.
 
C'est quel OS ?

n°529399
Taz
bisounours-codeur
Posté le 02-10-2003 à 16:32:22  profilanswer
 

nraynaud a écrit :


arriver à mapper tout la mémoire physique + tout le swap dans un seul process, c'est très fort.

le problème étant que sbrk n'est pas mmap

n°529402
nraynaud
lol
Posté le 02-10-2003 à 16:34:25  profilanswer
 

Taz a écrit :

le problème étant que sbrk n'est pas mmap

J'ai pas compris.

n°529408
Taz
bisounours-codeur
Posté le 02-10-2003 à 16:39:14  profilanswer
 

bien avec un système comme Linux, prenons le code de malloc. en fonction de la taille demandée, malloc fait soit un appel à mmap (projection de fichier en mémoire) soit un sbrk qui fait grandir le segment. mmap pour les grandes demandes, sbrk sinon. si sbrk échoue, c'est que FrenchKiss doit allouer une fourmillière de petits objets il me semble, et que l'interpréteur Perl est mal foutu de ce côté là peut être. bref, même si ça tourne, ça sens la fragmentation mémoire à plein nez :D

n°529415
nraynaud
lol
Posté le 02-10-2003 à 16:43:01  profilanswer
 

Taz a écrit :

bien en fonction de la taille demandée, malloc fait soit un appel à mmap (projection de fichier en mémoire) soit un sbrk qui fait grandir le segment

et il mappe quoi en mémoire avec mmap ? (je savais même pas qu'il utilisait ça)

n°529419
Taz
bisounours-codeur
Posté le 02-10-2003 à 16:45:58  profilanswer
 

ben quand tu fais sbrk, la mémoire physique est réclammée directement. quand tu fais avec mmap (utilisable pour projeter n'importe quel fichier), et bien il projete /dev/zero (du vide quoi) et n'alloue les pages qu'à l'utilisation. de plus que les mécanismes qui vont avec mmap sont beaucoup plus subtils. mais un peu plus lent donc réservé au grandes plages (aucun intéret pour quelques octets, il vont forcément être écrit immédiatement)
 
 
bref on dirait que l'allocateur Perl a du mal, est mal foutu, mais j'y connais rien du tout.


Message édité par Taz le 02-10-2003 à 16:46:54
n°529431
nraynaud
lol
Posté le 02-10-2003 à 16:51:49  profilanswer
 

Taz a écrit :

ben quand tu fais sbrk, la mémoire physique est réclammée directement. quand tu fais avec mmap (utilisable pour projeter n'importe quel fichier), et bien il projete /dev/zero (du vide quoi) et n'alloue les pages qu'à l'utilisation. de plus que les mécanismes qui vont avec mmap sont beaucoup plus subtils. mais un peu plus lent donc réservé au grandes plages (aucun intéret pour quelques octets, il vont forcément être écrit immédiatement)
 
 
bref on dirait que l'allocateur Perl a du mal, est mal foutu, mais j'y connais rien du tout.

Ah ok, merci.
 
Sinon, un allocateur normal double la taille à chaque fois, mais dans le cas de perl, je sais pas.

n°529592
pospos
Posté le 02-10-2003 à 18:42:50  profilanswer
 

le mode d'allocation de al memoire de perl est défnini au moment de la compilation de l'interpreteur perl. Je sais que j'avais pleins de galeres de memoire avec activeperl 5.6 (il rendait jamais al memoire, meme apres un undef franc et massif d'une variable), et ca marchait beaucoup mieux avec SiePerl 5.6 (un perl compilé par siemens). Mais toujours est-il qu'abvec avtive perl 5.8 tout est rentré dans l'ordre pour moi: il gere beaucoup mieux la memoire
 
donc frenchkiss, si tu utilise active perl 5.6 sous windows, essai de passer à la version 5.8 pour voir...

n°529596
frenchkiss
Posté le 02-10-2003 à 18:50:13  profilanswer
 

bon je suis sur le point de quitter le taf ,
j ai regarder la doc ($ENV{PERL_DEBUG_MSTATS}) sans grand succes pour l instant.
je suis sous unix et malheureusement (ou heureusement diront certain) je n ai pas encore tout pouvoir dans ma boite , donc va falloir que je me debrouille avec cette version de perl.
 
(j ai essayer en exportant cette etrange variable , de chiffres tres bizarres apparaissent )  
et meme documentes j y comprends rien ...
 
bon demain je m'y recolle  
 
merci pour vos reponses , si je trouve qqch je post.
 
FK
 
 

n°529618
nraynaud
lol
Posté le 02-10-2003 à 19:12:36  profilanswer
 

pospos a écrit :

il rendait jamais al memoire, meme apres un undef franc et massif d'une variable

c'est très très courrant ce type de comportement

n°530076
frenchkiss
Posté le 03-10-2003 à 09:56:00  profilanswer
 

si qqun connait l'equivlent de purify pour perl
bon j'my recolle (berk)
 
bon vendredi qd meme.

n°530113
nraynaud
lol
Posté le 03-10-2003 à 10:45:17  profilanswer
 

frenchkiss a écrit :

si qqun connait l'equivlent de purify pour perl

Perl ne corromp pas la mémoire par nature, c'est à un bug de la VM que tu es confronté, pas à un bug à toi. Tu ne peux que rapporter le bug aux auteurs et tenter de le contourner.

n°530124
frenchkiss
Posté le 03-10-2003 à 10:58:26  profilanswer
 

bah oui , mais faut bien qu il tourne mon prog, je dois donc connaitre cette limite pour pouvoir faire un work around (special dedicasse pour taz)

n°530302
pospos
Posté le 03-10-2003 à 14:35:11  profilanswer
 

check la five point height juste pour voir si ca work with

n°530322
pospos
Posté le 03-10-2003 à 14:45:47  profilanswer
 

Juste pour completer mon message sur le module qui permet de gagner de la place si on a un tres grand nombre d'instances:
http://search.cpan.org/~jasons/Cla [...] plate-0.7/
 
C'est un module qui etait decrit dans advanced programming in perl
 
En fait son principe c'est au lieu d'utiliser un hash pour chaque objet, avec les attributs de l'objet dedans, il cré un array pour chaque attribut de ta classe, mais commun à tous les objet: chaque instance a un rang auquel elle va chercher la valeur de chaque attribut dans le array correspondant
 
Donc si tu a 10000 objet et 5 attribut, au lieu d'avoir 10000 hash avec 5 entrée (ou 10000 array de longueur 5 comme avec le pragma fields, et c'est deja mieux que les hash niveau memoire et 15% plus rapide), et bien avec ce module tu aura 5 array de longueur 10000!
 
Il me semble que l'heritage est aussi prevu, mais bon dans ton cas ca te servira à rien de toutes facon vu que tu herite d'une classe qui n'est pas gerée comme ca...
 
Bon de toutes facon ce module est tres rarement utilisé on dirait, et le mieux c'est d'utiliser fields
 
De toutes facon tout ca sera reglé avec Perl 6! La syntaxe objet sera trop belle, un peu à la Ruby!! Enfin va falloir etre patient...
 
bon, desolé pour la digression...


Message édité par pospos le 03-10-2003 à 14:48:22
n°530336
pospos
Posté le 03-10-2003 à 14:50:12  profilanswer
 

un avant gout de la future syntaxe objet de Perl 6, pour deja l'avoir en Perl 5 (mais avec une implementation à base de filds derriere...).
 
http://search.cpan.org/author/LPAL [...] Classes.pm
 
(à ne pas utiliser pour de vrai, car comme c'est juste un filtre sur le code avant l'interpretation ca peut entrinaer des bugs etranges...)

n°530421
frenchkiss
Posté le 03-10-2003 à 16:08:57  profilanswer
 

interressant.
plus propre au niveau de la definition c sur.
 
finallement les langages finissent par beaucoup se ressmbler...
 
 
 
 

n°530449
Taz
bisounours-codeur
Posté le 03-10-2003 à 16:42:30  profilanswer
 

un Desin Pattern PoidsMouche/FlyWeight en somme

n°530462
frenchkiss
Posté le 03-10-2003 à 17:00:46  profilanswer
 

tu parles du rapport entre le langage et son interpretation je suppose.
 
bon sinon je fais des tests  
c assez bourrin , vu que comme j ai trouver aucun outil , j ai commenté certaines parties du cde ou je faisais des trucs un peu lourd ou des appels a la librairie dont je depends.
et je les recommente jusqu'a ce que je parte en out of memory.
bon c vrai rien ne me di que c est pas la somme de toutes les methodes decommentées qui pose le probleme plutot que la derniere ( je vous entends venir en criant au n importe quoi :) ).
mais zai pas le choix ( pis comme je l ai dit je fait pas grand chose a part des E/S dans fichier et appel a des methodes de comparaison)
 
je m aide de la variable specifiee dans ce post et qui me donne la memory allocation a la fin de chaque exceution.
ca varie peut quand je decommente certaine partie et ca explose juste si j ajoute un appel a une methode de diff (ecrite par le fameux expert qui m a plante...)
donc je crois avoir trouver la methode coupable.
 
reste a lui ouvrir les entrailles..
 
quel boulot de bourrin , tout ce temps a l ecole pour en arriver la , chui pas sur que c en vallait la peine :)
 
 

n°530777
pospos
Posté le 03-10-2003 à 22:04:57  profilanswer
 

en fait, tu crais des objets et du les efface ensuite? ou tous els objets doivent etre en memoire en meme temps?
 
si c'est el premier cas, peut etre qu'ils ne sont pas correctement detruits: Perl ne detruit un objet que si aucune reference à cet objet n'existe
 
Donc tu a peut etre laissé trainé une reference qq part?
 
essai de mettre une sub DESTROY dans ta classe, elle sera automatiquement appelée si l'objet et detruit, et dans ce cas c'est bon. Mais si elle n'est pas appelé c'est que l'objet n'est pas detruit...
 
donc fait simplement un truc du genre
 
sub DESTROY {
    my $self = shift;
    print $self->{nom} . " detruit\n";
}


Message édité par pospos le 03-10-2003 à 22:06:12
n°532434
frenchkiss
Posté le 06-10-2003 à 14:22:43  profilanswer
 

hello !!
 
bon alors j ai isoler la methode incriminee et fait un script qu appel cette methode 1000 fois ( comparaison entre 2 fichiers xml)
 
et paf , out of memory !!!
 
voila donc c'est sur c'est bien cette methode qui fou la zone  
(elle consomme eneormement de memoire)
 
 
merci et bonne semaine a tous ;)
 
 
 

n°532465
nraynaud
lol
Posté le 06-10-2003 à 14:40:03  profilanswer
 

Taz a écrit :

un Desin Pattern PoidsMouche/FlyWeight en somme

Non, dans le cadre du poidsmouche il change de représentation. La complexité totale ne change pas mais il a une représentation plus efficace.

n°538313
frenchkiss
Posté le 13-10-2003 à 15:46:39  profilanswer
 

up ! pour en revenir a mon probleme c'est resolu ,  
c'etait bien la methode qui posait probleme.
 
mais vous aller rire..
 
imaginez que vous avez un fichier de 10 739 438 lignes..
a parser ( extraction d'info)
quel solutions mettreriez vous en oeuvre?
par ce qu'a priosi un open  provoque un ..
 
Our of memory during "large " request...
 
(enfin pas le open en lui meme , mais le <FILE> )
 
toujours en perl 5.6.1

n°539000
pospos
Posté le 14-10-2003 à 10:18:26  profilanswer
 

Ha c'etait ca?
Ben c'est sur que si tu fais un truc genre
@a = <FILE>
ca va charger la totalité du fichier dans @a, mais si tu fait un:
while(<FILE> ) {...
la ca va le faire ligne par ligne...
 
je suis un peu déçus...

n°539020
frenchkiss
Posté le 14-10-2003 à 10:35:08  profilanswer
 

non le probleme inititail etait du a des cycles dans un graphe
d'objet ( representant le fichier XML) , j en sais pas vraiment plus , vu que ce n'est pas moi qui cree ce graphe , j ai recu un patch et plus de soucis.
 
ce probleme etant resolu mon script a tourne et ma genere ce fameux fichier de 10 millions de lignes , et une fonction appellee qvec ce fichier en parametre (avec regexp) etait pas trop prevue pour avaler tant de donnée (undef $/)  , je l ai effectivement modifiee et ca roule.
 
enfin comme tu le dis pospos ce 2eme etait tres facile a identifier ( ffectivement).
 
bon voila tout tourne maintenant !

mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Perl

  [perl] sbrk échoue, problème de consommation mémoire excessive

 

Sujets relatifs
Problème de date en php[thread/linux/c++/kdevelop3.1] Problème avec les threads
aide perl/Tk explication sur le placement SVP.Problème "Insert" pour débutant
simple CSS problemeProblème d'échappement avec l'apostrophe ou '
[Html - CSS] problème de décalageJakarta Tomcat : probleme d'execution
Probleme d'affichage avec une page en asp.net[Problème] Passage servlet -> JSP, et mappage web.xml
Plus de sujets relatifs à : [perl] sbrk échoue, problème de consommation mémoire excessive


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR