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

Après moult investigations, il semble presque sûrement que le problème vienne de Velocity 1.6.4 que nous utilisions.
Notez la prudence et le fait que c'était bien la dernière version dite stable.

JProfiler que j'avais tenté en version d'évaluation pour l'occasion n'a rien détecté.
La mémoire totale du process montait jusqu'à 10Go provoquant un swap monstrueux et JProfiler n'a rien vu.
De son point de vue, la JVM devait faire 80Mo dont 20 de libre.

Après isolation successive des sections du code, il est apparu que la section utilisant Velocity était fautive.
En effet, quand cette section était commentée, le problème disparaissait.

J'ai tenté d'utiliser Velocity 1.7 beta 1 et le problème n'est plus réapparu.
Je n'ai pourtant pas noté de spécial dans la release note, mais cela ne prouve rien car la release note est plutôt orienté feature.
Nous faisons il est vrai un usage conséquent des macros qui se trouvent justement avoir été améliorée dans la 1.7 ... mais c'est un peu léger pour conclure.

Nous avons donc basculé sur cette version dite non stable et tout est Ok pour l'instant.

Je ne comprends toujours rien, mais au moins çà fonctionne.

Ce qui me pose question :
1. Comment une librairie "pure Java" comme Velocity peut-elle provoquer une telle catastrophe au niveau mémoire ? (pas de code natif dans Velocity).
2. Comment est-il possible qu'un profiler sérieux comme JProfiler ne voit rien ?
3. Comment est-il possible que le système enregistre une telle quantité de mémoire sans que cela nécessite un réglage spécial de la JVM ?
Je n'avais aucun réglage mémoire particulier.

Serais-je tombé sur une combinaison fatale provoquant un bug de la JVM elle-même ? Bien sur, c'est possible, mais si peu probable ...
Reproductible MacOS et Linux. Pas testé sous Windows.

Une autre hypothèse ??


On 5 nov. 2010, at 11:32, Jean-Baptiste BRIAUD -- Novlog wrote:

> 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 !
> 
>