De manière inattendue, la taille du tas est supérieure à% utilisée

Avoir une question d’allocation de mémoire avec laquelle j’aimerais avoir votre aide. Nous avons analysé certains de nos services en haut et nous notons qu’ils ont une valeur de RES d’environ 1,8 Go, ce qui, pour autant que je sache, signifie qu’ils conservent 1,8 Go de mémoire à ce moment-là. Ce qui serait bien si nous venions de les lancer (ils lisent essentiellement à partir d’un cache, effectuent le traitement et poussent vers un autre cache), mais comme nous voyons toujours cela une fois le traitement intensif terminé, nous nous demandons si signifie que quelque chose n’est pas GC ‘on s’attendait.

Nous exécutons le programme avec les parameters suivants: -Xms256m -Xmx3096m qui, si j’ai bien compris, signifie une taille de segment initiale de 256 et une taille de segment de mémoire maximale de 3096.

Maintenant, ce à quoi je m’attendais à voir, c’est que le segment de mémoire croît au besoin initialement, puis se réduit au besoin au fur et à mesure que la mémoire devient désallouée (bien que cela puisse être ma première erreur). Ce que nous voyons avec jvisualvm est le suivant:

3 minutes dans: le tas utilisé est de 1 Go, la taille du tas est de 2 Go
5 minutes dans: nous avons terminé le traitement, donc les sauts de tas utilisés de façon spectaculaire à près de zilch, la taille du tas ne diminue cependant que d’environ 1,5 Go
7 minutes ->: petits bits de traitement en temps réel périodiquement, tas utilisés entre 100 et 200 Mo environ, mais la taille du tas rest constante à environ 1,7 Go.

Ma question serait, pourquoi mon tas n’a-t-il pas diminué comme je m’y attendais peut-être? Est-ce que cela ne dérobe pas les autres processus sur la boîte Linux de la mémoire précieuse, et si oui comment pourrais-je le réparer? Nous constatons parfois des erreurs de mémoire, et étant donné que ces processus se voient atsortingbuer la taille de mémoire la plus “inattendue”, j’ai pensé qu’il était préférable de commencer avec eux.

Cheers, Dave.

(~ excusez le manque de compréhension possible sur le réglage de la mémoire JVM!)

Vous voudrez peut-être voir cette réponse sur le réglage de l’extension du segment de mémoire et sur sa réduction. Par défaut, la JVM n’est pas trop agressive pour réduire le tas. En outre, si le tas dispose de suffisamment d’espace libre pendant une longue période, il ne déclenchera pas de GC, ce qui, je pense, est le seul moment où il est envisagé de le réduire.

Idéalement, vous configurez le maximum à une valeur qui donne à votre application une marge suffisante à pleine charge, tout en étant acceptable pour les performances du système d’exploitation si elle est toujours utilisée. Il n’est pas rare de fixer le minimum au maximum pour assurer la prévisibilité et potentiellement de meilleures performances (je n’ai rien à référencer pour cela).

Je n’ai pas de réponse complète, mais une question similaire a déjà été posée . À partir de la discussion précédente, vous devez examiner -XX:MaxHeapFreeRatio= comme paramètre d’ -XX:MaxHeapFreeRatio= pour forcer la libération du -XX:MaxHeapFreeRatio= sur le système d’exploitation. Il existe une documentation ici , et je pense que la valeur par défaut permet à la JVM de conserver une très grande quantité de tas inutilisés.

Eh bien, le GC ne s’exécute pas toujours quand on pense et il ne collecte pas toujours ce qui est admissible. Cela pourrait tout aussi bien commencer que collecter des objects de l’espace de l’ancienne génération s’il est presque à court d’espace de tas (puisque collecter de l’ancienne génération impliquerait normalement une collection stop-the-world que le GC essaie d’éviter jusqu’à ce qu’il ait vraiment besoin de le faire). il).

Peut-être pourriez-vous essayer un profilage, avec TPTP, visualvm ou JProbe (commercial, mais disponible à l’essai), pour savoir exactement ce qui se passe.

Une autre chose à surveiller est les gestionnaires de fichiers; Je n’ai pas les détails mais un de mes collègues a rencontré il y a quelques années un problème de saturation de tas provoqué par un processus qui a ouvert de nombreux fichiers et a découvert que chaque fois qu’il en ouvrait un, un tampon de 4 Ko était libéré à la fin de son traitement. J’espère que ces indications assez vagues peuvent aider …