Nous avons une application basée sur Java qui fonctionne sur JBoss avec une taille de tas maximale autorisée d'environ 1,2 Go (la mémoire physique totale de la machine est de 2 Go). À un moment donné, l'application cesse de répondre (aux clients) pendant plusieurs minutes. Après quelques analyses, nous avons découvert que le coupable est le GC complet. Voici un extrait du journal détaillé GC:Le temps réel du GC complet est beaucoup plus que l'utilisateur + sys fois
74477,402: [GC complet [PSYoungGen: 3648K-> 0K (332160K)] [PSOldGen: 778476K-> 589497K (819200K)] 782124K-> 589497K (1151360K) [PSPermGen: 102671K-> 102671K (171328K)], 646.1546860 secs] [temps: user = 3,84 sys = 3,72, real = 646.17 secondes]
ce que je ne comprends pas comment est-il possible que le temps réel passé sur GC complet est d'environ 11 minutes (646 secondes), tandis que utilisateur + sys fois sont juste 7,5 secondes. 7,5 secondes sonne beaucoup plus de temps logique à dépenser pour le nettoyage < 200 MB de l'ancienne génération. Où va tout le reste du temps?
Merci beaucoup.
Une autre approche pourrait être de réduire les objets à longue durée de vie, car les objets de courte durée seront recyclés beaucoup plus rapidement. Object-Pooling par exemple est une mauvaise pratique en Java. –
True. Je me concentrais sur des choses que le PO pouvait faire rapidement pour résoudre le problème. –
Êtes-vous sûr de cela? Je m'attendais à ce qu'un processus JVM en attente d'un pagein passe le temps dans sys =. – eckes