RE: Problème de mémoire qui, en apparence, défie la logique

Dans ce cas là il faudrait utiliser un profiler natif pour pouvoir tracer l'origine des allocations de mémoire. Je n'ai jamais utilisé ce genre de chose mais je ne vois que ça pour aider à diagnostiquer le problème.

> -----Message d'origine-----
> De : Jean-Baptiste BRIAUD -- Novlog [mailto:[email protected]]
> Envoyé : vendredi 5 novembre 2010 12:07
> À : strasbg Java
> Objet : Re: Problème de mémoire qui, en apparence, défie la logique
> 
> Je n'y aurait pas pensé...
> Donc, pas de code natif directement, mais indirectement : oui, du
> python.
> tout cela est lancé via des scripts ant qui tournent tous dans des
> process bien séparé.
> Je ne vois donc pas de raison pour que le process père soit affublé
> d'une telle quantité de mémoire : quand le process fils qui lui même
> lance python (via une tâche ant exec) se termine, toute la mémoire est
> libérée.
> 
> 
> On 5 nov. 2010, at 11:38, <[email protected]>
> <[email protected]> wrote:
> 
> > N'y aurait-il pas du code natif quelque part qui ne libèrerait pas la
> mémoire?
> >
> > My 2 cents.
> >
> > Patrice
> >
> >
> >> -----Message d'origine-----
> >> De : Jean-Baptiste BRIAUD -- Novlog [mailto:[email protected]]
> >> Envoyé : vendredi 5 novembre 2010 11:33
> >> À : strasbg Java
> >> Objet : Problème de mémoire qui, en apparence, défie la logique
> >>
> >> Bonjour à tous,
> >>
> >> J'ai un problème. J'ai une JVM avec Tomcat (6.0.29 au cas où ce soit
> >> important) et "tout un bazar" serveur qui tourne.
> >>
> >> Je lance le client, le process serveur vu du système fait quelques
> >> bonne dizaines de Mo.
> >> Je lance via le client une action sur le serveur. Après l'action, le
> >> process serveur vu du système fait 200/300 Mo, ce qui est conforme
> aux
> >> attentes.
> >> Je refait la manip 2 fois (3 en tout, donc) et là, le process
> serveur
> >> s'emballe et vu du système il occupe 3/5Go de mémoire et cela peut
> >> encore monter alors que l'action est complètement finie coté serveur.
> >>
> >> Je me précipite sur un profiler mais à ma grande surprise rien !
> >> Le process, vu du profiler, après la 3eme action, alors même que le
> >> système annonce plus de 3Go de "mémoire réelle" (plus de 10Go de
> >> mémoire virtuelle !!!) le profiler ne voit que 80Go en tout dont 20
> de
> >> libre.
> >>
> >> Je ne comprends rien !
> >>
> >> Coté "pure Java", tout semble OK. La machine devient cependant quasi
> >> inutilisable à cause des IO généré par un tel process à cause du
> swap
> >> (10Go de mémoire virtuelle).
> >> Ca n'est donc pas une espèce d'erreur de mesure, le process est bel
> et
> >> bien énorme, mais semble t-il pas coté Java, pourtant, c'est bien le
> >> process d'une JVM, dingue non ?
> >>
> >> Je tourne sous Mac OS, alors évidement, la question suivante est :
> est-
> >> ce reproductible sous Linux par exemple ? Et bien oui ! Même
> >> comportement.
> >>
> >> Bref, le problème est bien réel et parfaitement reproductible.
> >>
> >> Ce process présente quelques caractéristiques ayant une chance
> d'être
> >> responsable du problème, mais pourquoi le profiler ne voit rien ?
> >> 1. Le process lance d'autre process via le lancement de ant
> >> 2. Le process produit pas mal de fichiers via Apache Velocity (qui
> >> semble présenter des memory leak vue du profiler, mais on parle en
> >> dizaine de Ko de memory leak ...)
> >>
> >> Une idée ? Une manip à tenter ?
> >>
> >> Qu'est-ce qui pourrait occuper la mémoire sans se faire voir par un
> >> profiler de JVM ?
> >>
> >> Merci !
> >>
> >
> >
> > *********************************
> > This message and any attachments (the "message") are confidential and
> intended solely for the addressees.
> > Any unauthorised use or dissemination is prohibited.
> > Messages are susceptible to alteration.
> > France Telecom Group shall not be liable for the message if altered,
> changed or falsified.
> > If you are not the intended addressee of this message, please cancel
> it immediately and inform the sender.
> > ********************************
> >


*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************