Répartition de la mémoire Java

Version imprimable

26/10/2009, 17h19
hasalex

Répartition de la mémoire Java

Bonjour,

Je suis en train d'essayer de comprendre comment est constitueé la mémoire d'un processus Java.
Ce que j'avais compris, c'est qu'il y a la heap (commandée par -Xmx et -Xms), le perm space (commandé par -XX:MaxPermSize et -XX:PermSize ), le code cache (commandé par -XX:ReservedCodeCacheSize et -XX:InitialCodeCacheSize) et le stack par thread (commandé par -Xss et -XX:ThreadStackSize).

A partir de là, je m'étais imaginer qu'en additionnant tout cela, je devais obtenir à peu de chose près la taille mémoire allouée au processus. Et bien non ! J'ai deux exemples, tous deux des applications Web, sous Tomcat 6, avec un JDK 6. Autant dans le premier cas, ça ne m'a jamais alerté, autant dans le deuxième cas, la différence est importante et peut me poser des problèmes.

Premier cas :
Sous Linux 32bits : heap=512Mo, Perm=256Mo, CodeCache=48Mo, StackSize=1Mo avec 21 threads
Si j'additionne tout ça, j'obtiens 837Mo, alors que mon process utilise 873Mo.

Deuxième cas :
Sous Linux 64bits : heap + perm + code cache=4096 Mo, StackSize=1Mo avec 250 threads => 4350 Mo, et mon process utilise 1500 Mo de plus !

De quel coté dois-je regarder pour trouver ce qui occupe mes 1500 Mo ? Si vous avez des pistes, merci...
26/10/2009, 20h40
Invité

Salut,

La jvm alloue de la mémoire à l'avance, donc le processus prend plus de place que ce qu'il utilise vraiment.
Tu peux voir cette différence avec un outil du genre jvisualvm (inclus avec le jdk depuis la version 1.6b10) qui permet de visualiser la mémoire.

A plus
26/10/2009, 22h35
hasalex

J'ai peut-être raté quelque-chose avec jVisualVM, mais je ne vois pas comment explorer autre chose que la heap. Or, je n'ai aucun problème avec la heap.

Peux-tu m'expliquer comment je dois procéder pour explorer ce qui n'est ni dans la heap, ni dans le perm space, ni dans les stacks ? Je suppose que ce qui reste est du ressort de librairies natives et de buffers avec l'OS, mais comment en savoir plus ?
27/10/2009, 10h21
tchize_

Citation:

Envoyé par hasalex

De quel coté dois-je regarder pour trouver ce qui occupe mes 1500 Mo ? Si vous avez des pistes, merci...

Est-ce que tu n'aurais pas utilisé, par hasard, cette commande pour mettre un stack de 1M?

Code:

-XX:ThreadStackSize=1M

Car l'unité de base de ce paramètre est le kilobyte, en tappant 1M tu alloue alors 1024*1024 kilobyte par stack, ce qui donne 1G. J'ai essayé ici, avec 200 thread et ce paramètre, je monte bien à 204G de mémoire virtuelle pour le process sur système 64 bits.

edit: pour les autre variation, ta mémoire peut etre occupée par les système suivant

-> mappings dus à java.nio, ce mapping mémoire n'occupent pas de ram ni de place dans la JVM, a ce titre ils ne sont pas limités (c'est de la mémoire disque dur accessible via la zone mémoire du process, mais pas présent en RAM)
-> données venant d'autre process et partagées. Ces données appartiennet peut etre aux autres process, mais comme le noyaux ne sais pas nécessairement qui en est propriétaire, ca apparait dans ta liste d'occupation. Exemple, les données partagées par l'interface graphique si tu utilise awt
-> librairies de la jvm et nécessairement mappée en mémoire. Ca doit vaire une 20aine de M, qui sont alloués par l'OS avant le démarrage de la JVM et qui n'entrent pas en compte
-> Donnée allouées par des librairies native. Si l'allocation se fait avec un malloc bien brut, la jvm n'a aucun controle dessus
->
27/10/2009, 10h32
hasalex

Non, il n'y a aucun problème de stack. J'ai d'ailleurs pu vérifier sa valeur (1024k) avec pmap.

Ce qui me tracasse, c'est ce qu'il y a à coté des zones classiques (heap, stacks, perm, code cache). Je suppose qu'il s'agit de mémoire utilisée par des librairies native ou des buffers avec l'OS. Mais comment en savoir plus ?
27/10/2009, 10h38
tchize_

quelle mesure de mémoire utilise-tu? Rien qu'avec top, il y a déjà 3 colonne concernant la mémoire.
27/10/2009, 14h20
hasalex

Je parle de Virtual Mémory. En effet, c'est celle-ci que peut poser des problèmes de limitation au niveau de l'OS. Une bonne partie de la différence entre virtuelle et résidente vient du fait que Xmx > Xms et MaxPermSize > PermSize.
pmap m'indique que presque toute la mémoire inconnue est résidente.
27/10/2009, 14h49
tchize_

as-tu vérifié la mémoire réellement utilisée avec

cat /proc/<pid>/status

La colonne VIRT dans top n'est qu'un information sur l'espace d'adressage utilisée par l'application, ca n'a rien a voir avec la mémoire qu'elle a réservé et n'est pas un indication des besoins en mémoire de ton application. Si je crée en C un application qui est capable de travailler avec 100k de mémoire mais qui fait un mmap de 5 fichier de 100G, je vais avoir un VIRT qui dépasse alègrement les 500G.

Il 'suffit' que t'ai 1 page de donnée mappée dans la zone d'adressage de 16G, par exemple, avec un gros trous de 15,99G entre celle-ci et la base de ton programme, pour que la colonne VIRT de ton process donne 16G.

Je parviens, sans problème ici, à faire grimper le VIRT d'un JVM (ok, je pousse le bouchon mais bon) à 2.5 tera de mémoire, et pourtant, comme une grande, la JVM lance des out of memory exceptions dès que j'atteinds les 512M autorisés par ses commandes, sans vraiment requérir de mémoire du système.

Bref, la colonne VIRT n'est certainement pas à prendre en compte pour mesurer les besoin d'une application (quelle soit java ou autre). La mesure la plus proche se situe dans la zone [RES-SHR,RES] quand tu n'a pas de swap.

Et la différence VIRT / RES n'est absolument pas liée à la différence permsize/maxpermsize, heapsize/maxheapsize, car cette gestion est inconnue de l'os, c'est la jvm qui alloue ou pas des segment de mémoire en fonction de la charge via des appels realloc()

Il y a plein de chose qui peuvent augmenter l'espace d'adressage dans une application, sans pour autant nécessiter de la RAM, car plein d'opération système se font sur base de pages d'adresses (accès à des périphérique, accès plat à des fichiers, accès à des ressources partagée, communications inter process, etc).