Je suis nouveau à Java et je viens de hériter d'une configuration de Tomcat, alors j'aimerais avoir des conseils :) J'ai lu plus dans la semaine dernière à propos de JVM Tuning et des algorithmes de collecte de poubelles que je voudrais!
Utilisation de Visual VM / GC Nos serveurs Tomcat font moins de gc de GC une fois par jour. Étant donné que la plupart des sessions Web des utilisateurs durent moins d'une heure, celle-ci semble très peu fréquente et il y a probablement beaucoup d'objets "morts" dans Perm Gen depuis longtemps? Cela signifie-t-il simplement que nous avons beaucoup d'espace RAM / tas, et il n'a tout simplement pas besoin de collectionner pour que ce ne soit pas?
Compte tenu de cela, serait-il préférable de rendre l'ancien général plus petit et le nouveau général, car le taux de promotion est très petit?
Je demande, car il y a des indications ailleurs dans le système d'exploitation que nous pourrions avoir des pressions de mémoire, mais les journaux JVM / GC semblent contredire le système d'exploitation.
liée à cela -
Nous avons actuellement est-il préférable de quitter la JVM pour se syntoniser plutôt que d'être obésé avec des paramètres tous les paramètres manuellement ou la plupart des gens définissent les paramètres manuellement? min-heap = max-heap = 6GB . Si haut affiche une taille de processus Java de 7-8 Go, mais un RSS de 5-6 Go, cela signifie probablement que 2 Go est échangé? Dans ce cas, il fait de mourir quand il est complet GCS. Donc, il serait préférable d'avoir une taille plus petite min-heap que GCS plus souvent avant que le système d'exploitation ne sonne pas.
3 Réponses :
de mon expérience, je pense que les déclarations
"Les serveurs font moins de gc de GC qu'une fois par jour"
et
"Il y a des indications ailleurs dans le système d'exploitation que nous pourrions avoir la mémoire pressions "
se contredisent les uns aux autres. Généralement, la fréquence de GC augmente avec la baratte de mémoire, et moins souvent cela se produit, mieux c'est.
N'oubliez pas que GC complet signifie que toute l'activité d'application est arrêtée - parfois cela peut prendre des minutes, en particulier pour les grands tas!
Par exemple, Ici, j'ai un certain nombre de systèmes en direct avec ~ 1.4K Sessions HTTP chacun et chaque case (
-xmx = 13g ) environ 1-2 GCS complet par heure . Idéalement, nous aimerions que cela soit encore moins fréquent, mais en raison de la nature de l'application, nous ne pouvons pas.Vous devez clarifier quel est le problème authentique que vous essayez de résoudre, car à partir des informations que vous avez données, je ne vois rien qui nécessite un réglage.
Il s'agissait d'une question générale pour avoir une idée de la fréquence «normale» de GCS et si ma compréhension de l'espace Perm / Eden était correcte. Nous utilisons le GC simultané pour essayer d'éviter les événements d'arrêt-le-monde. Au fil du temps, la mémoire libre sur les serveurs (comme indiqué par haut ) va bas (<500 Mo), puis le serveur ralentit sur une analyse. Il existe actuellement une proposition que nous ajoutons plus de mémoire à nos serveurs pour résoudre ce problème. Pour moi, il est plus indicatif d'une fuite de mémoire quelque part, donc nous n'avons pas besoin de plus de RAM. J'étais curieux si avoir des taux aussi bas de GC complètes signifiaient que Java avait déjà beaucoup de RAM
Ah, j'avais supposé que vous utilisiez l'ancien GC, pas le nouveau G1 GC. Aurait pu mentionner ça.
La collecte des ordures est un compromis entre l'allocation de mémoire et la performance. Imaginez votre grenier. Si vous continuez à jeter des choses dedans, cela finira par aller plein et vous devrez le nettoyer. Si vous avez un petit grenier, vous pourriez le remplir une fois par mois, mais cela ne vous prendra que 20 minutes pour ranger. Si vous avez un très gros grenier, cela pourrait vous emmener une année à remplir, mais un week-end pour nettoyer.
La même chose est vraie de la JVM. Si vous allouez 6 Go, mais que vous pourriez vraiment passer avec 1,5 Go, vous aurez alors des collections de déchets beaucoup moins fréquentes, mais quand elles se produisent, cela pourrait arrêter le monde pendant plus d'une minute.
Si les scaves (copier d'Eden à survivant) récupérent la plupart de la mémoire, vous avez beaucoup d'objets très courts. Si vous augmentez la taille de la nouvelle génération, ces collections à ordures deviendront moins fréquentes, mais elles prendront plus de temps. Idéalement, vous voulez que cela soit aussi rapide que possible, ce qui signifie de garder cet espace suffisamment petit pour pouvoir balayer rapidement, mais suffisamment grosse que les objets de courte durée ne se préparent pas à la génération titulaire. Je ne voudrais pas bricoler de la taille de la nouvelle génération, sauf si j'étais sûr que les objets courts de la vie (c'est-à-dire de la demande) sont en cours d'occupation quand ils ne devraient pas être.
Si cela vous prend quelques jours maintenant pour remplir 6 Go, étant donné que le tas accumule des objets de chaque session d'utilisateur et que vous avez déjà eu depuis le dernier GC , je ' d Suspect que vous libérez une bonne morceinte de votre tas avec le GC complet. Si vous n'êtes pas, alors vous devriez probablement rechercher si vous avez une fuite de mémoire (peut-être une cache de voyous). Si vous libérez la majeure partie du tas avec le GC complet, vous devez rechercher si une taille de tas plus petite aurait un sens.
Un tas plus petit augmentera la fréquence des collections à ordures complètes, mais rendrait les pauses beaucoup plus courtes. Dans une application Web, les pauses du monde à long terme pour les collections à ordures complètes sont inacceptables si elles se produisent pendant une période de pointe.
Si, comme vous l'indiquez, le tas Java est potentiellement échangé par le système d'exploitation, vous devez certainement regarder la rétrécissement. Mais je ne serais pas altérer avec le dimensionnement de la nouvelle génération. Combien de mémoire est libérée par votre collection à la poubelle complète?
Coût de la collecte d'Eden Généralement, la taille de la Live Set n'est pas la taille d'Eden, de sorte que le conseil de garder Eden petit est trompeur. Comme vous l'avez fait allusion, une chose essentielle est de vous assurer que les espaces de survivants sont correctement dimensionnés et maxtenuringthreshold sont correctement définis afin que la tenure inappropriée ne se produise pas.
Ah Cool ... Ouais, je suppose que cela fait du sens Re: le live set. Merci de clarifier.
Cool merci! Ont réalisé (en utilisant PMAP sur le processus Java) que la raison de notre situation MEM faible est que, de temps en temps, le processus Java mais pas le java tas Spikes d'environ 200 Mo à 3 Go! Besoin de savoir ce qui cause cela maintenant. Pensez que je vais rétrécir la taille maximale du tas ainsi de sorte que cela gc est plus souvent, mais avec moins d'impact à chaque fois.
Quelle version de tomcat utilisez-vous?
Il y a un bug dans les gubbins de prévention des fuites de mémoire qui provoque GC complètes sur l'heure:
"Est-il généralement préférable de quitter la JVM pour se syntoniser" - est une performance GC un goulot d'étranglement inacceptable?