JVM IBM 1.6.0 SR7 – attention au Garbage Collector

Last Updated on Vendredi, 30 avril 2010 01:17 Written by Henri Gomez Lundi, 15 février 2010 11:48

J’ai mis à jour la JVM IBM 1.6.0 d’un de nos systèmes Linux Suse SLES 10 sous VMWARE ESX.

A priori rien de bien terrible, un passage de la JVM de SR6 à SR7, rien de spécial dans le changelog à part la liste habituelle de corrections de bugs.

Peu de temps après, on me signale une consommation CPU anormale. La commande top confirme que les JVM tournent entre 70 et 80% alors qu’il n’y a aucun activité particulière.

Un peu coup d’oeil via JConsole montre un comportement anormal du Garbage Collector. Je repasse une des instances en SR6 et relance 2 instances similaires, une en SR6 et l’autre en SR7 :

Vue du Garbage Collector via JConsole

IBM 1.6.0 SR6

Etat du Heap sous IBM SR6

Un seul type de garbage, 2s maximum

IBM 1.6.0 SR7

Beaucoup plus d'activité de garbage collection en SR7

Un GC utilisant les méthodes Copy et MarkSweepCompact

On voit une activité GC plus constante, d’où la consommation de CPU qui passe du coup de 2s à 20s et ce même en absence totale d’activité coté Tomcat.

Politiques de GC sur JVM IBM

Les 3 politiques de Garbage Collection sur une JVM IBM pour x86 sont :

• -Xgcpolicy:optthruput (Default and recommended value.) : Delivers very high throughput to applications, but at the cost of occasional pauses.
• -Xgcpolicy:optavgpause : Reduces the time spent in garbage collection pauses and limits the effect of increasing heap size on the length of the garbage collection pause. Use optavgpause if your configuration has a very large heap.
• -Xgcpolicy:gencon : Requests the combined use of concurrent and generational GC to help minimize the time that is spent in any garbage collection pause.

On a donc :

• une stratégie de GC qui donne de très bonne performance pour votre application mais avec des périodes de pause.
• une méthode moyenne où le GC dure moins longtemps.
• une GC qui tourne plus souvent en faisant des opérations de collectes plus courtes et donc réduisant les temps de pause.

Problème, quelque soit le réglage de GC on a le même comportement et une consommation CPU excessive.

Conclusion

Une mise à jour d’apparence anodine surtout que rien n’indique dans la changelog que quelque chose ait changé dans le mode de fonctionnement du GC.

En attendant d’avoir un comportement correspondant aux attentes et tenant compte des réglages JVM, c’est retour à la version SR6.

Soyez-donc prudent.