Discussion :

[felix79]

Bonjour

On viens de me signaler un plantage sur un serveur lié à un OutOfMemory java, voici la trace correspondante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
java.lang.OutOfMemoryError: allocLargeObjectOrArray - Object size: 76864, Num elements: 38424
                at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99)
                at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393)
                at java.lang.StringBuffer.append(StringBuffer.java:225)
                at java.util.regex.Matcher.appendTail(Matcher.java:762)
                at java.util.regex.Matcher.replaceFirst(Matcher.java:849)
                at java.lang.String.replaceFirst(String.java:1967)

Je ne comprend pas comment un bête "replaceFirst" peut déclencher ça !
Voilà le code correspondant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

page = page.replaceFirst("#HEADERS#", p_headers);

page est une variable donc le contenu de départ est connu, par contre je ne sais pas ce qu'il y a dans p_headers....
Si qqun a une idée de ce qui peut provoquer ça je suis preneuse !

Par ailleurs, est ce que qqun peut me confirmer la signification de la 1ere ligne de l'erreur (Object size: 76864, Num elements: 38424), est ce que ça signifie que java a essayer d'allouer 76864 * 38424 = 2 953 422 336 octets ???

[tchize_]

Comme souvent avec des outofmemory dus à des memoryleaks dans ton application, ce n'est pas l'endroit où a lieu l'erreur qui compte. A moins bien sur que ta String sur laquelle tu fais le replace occupe quelques G tellement elle est grande...


Ta mémoire est devenue tellement limite avec le temps que la moindre demande peut aboutir à un OOM. Ici tu as un objet page, qu'on peux supposer pesant quelque centaines de k (typique d'une page web) qui a besoin de faire une copie de lui même pour le replace, en gros, et qui n'a pas les 100k supplémentaires demandés.

Ce qu'il te faut cherche c'est où est passé ta mémoire. Et là il n'y a pas d'avance, il faut utiliser un profiler qui te fera des statistiques sur les objets les plus gourmands de ton application, c'est en général quelques juors de travails pour analyser cela quand on n'a pas trop l'habitude. Et un dev qui a l'habitude des Out of memory... C'est dangereux

[kolodz]

Quand tu réalisé un replace dans un String en Java, tu crée systématiquement un nouvel objet en mémoire. Tu as la même problématique quand tu concatène des String sans passé par un StringBuilder.

Si tu recherche cette erreur sur le web tu trouvera d'autre personne ayant aussi cette problématique. L'une des solutions proposé est la modification des paramètres de lancement.

Pour le détail de l'erreur, je ne suis pas exactement sûr de la signification. Dans le doute, je ne préfère rien te confirmer ou infirmer.

Cordialement,
Patrick Kolodziejczyk.

[felix79]

La fuite mémoire est bien sur possible, mais ca m'étonne : c'est une appli qui tourne en prod depuis des années, si c'était le cas on devrait avoir des plantages régulièrement.....
Et que penser de Object size: 76864 qui laisse penser qu'il s'agit d'un gros objet alors que l'objet page est beaucoup plus petit (663b exactement)... A moins que ce soit p_header qui soit très gros, je vais essayer de vérifier si c'est possible

[kolodz]

Après, cela est peut-être un effet de bord d'une autre application.
Par exemple, si une autre application a été lancé en même temps, il est possible que celle-ci consomme l'intégralité de la mémoire disponible. Ainsi Java n'est pas capable d'alloué de la mémoire supplémentaire. Car déjà prise par un autre programme.

Peut-être aussi regarder si il y a eu un changement dans les versions utilisées. Peut-être qu'une configuration a été perdu.

Cordialement,
Patrick Kolodziejczyk.

[felix79]

Merci de votre aide.
J'ai lancé qq perches dans ce sens (je n'ai pas accès moi même à la machine) et on va voir ce que ça donne, mais j'y crois pas trop : difficile d'analyser ce genre de pb à postériori ! On va essayer de surveiller la conso mémoire...

[tchize_]

La jvm peut être configurée pour faire un dump lors d'un outofmemory, qui pourra être analysé avec des outils de profilage afin de déterminer ce qui occupait la mémoire au moment de l'erreur. Ce dump est peut être déjà là.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

-XX:-HeapDumpOnOutOfMemoryError

Chercher un fichier .hprof qui correspond au moment du crash