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

C'est quoi les valeurs -Xms -Xmx
Les chiffres sont pas clair dans ton message :
> 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

Regarde aussi avec visualvm ( c'est dans le jdk ), c'est pas un profiler
mais il te donnera les valeurs de la heap free/used sous forme de graph.

Dominique


2010/11/5 Jean-Baptiste BRIAUD -- Novlog <[email protected]>:
> 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.
>> ********************************
>>
>
>