Mon serveur JBoss atteint 100% CPU SYS sous Linux; qu'est-ce qui peut causer ça?

Question

Nous avons débogué ce problème de serveur JBoss pendant un certain temps. Après environ 10 heures de travail, le serveur se lance dans des attaques de panique à 100% du processeur et s'arrête. Pendant ce temps, vous ne pouvez pas exécuter de nouveaux programmes, donc vous ne pouvez même pas kill -quit pour obtenir une trace de pile. Ces charges élevées du processeur SYS à 100% durent de 10 à 20 secondes et se répètent toutes les quelques minutes.

Nous avons travaillé pendant un certain temps. Nous soupçonnons que cela a quelque chose à voir avec le GC, mais nous ne pouvons pas le confirmer avec un programme plus petit. Nous fonctionnons sur i386 32bit, RHEL5 et Java 1.5.0_10 en utilisant -client et ParNew GC.

Voici ce que nous avons essayé jusqu'à présent:

1. Nous avons limité l'affinité du processeur afin que nous puissions utiliser le serveur lorsque les coups de charge élevée. Avec strace nous voyons une boucle sans fin de SIGSEGV, puis le retour sig.

2. Nous avons essayé de reproduire ceci avec un programme Java. Il est vrai que SYS CPU% monte haut avec WeakHashMap ou lors de l'accès aux pointeurs NULL. Le problème était que fillStackTrace a pris beaucoup de CPU utilisateur% et c'est pourquoi nous n'avons jamais atteint 100% SYS CPU.

3. Nous savons qu'après 10 heures de stress, le GC devient fou et le GC complet prend parfois 5 secondes. Nous supposons donc que cela a quelque chose à voir avec la mémoire.

4. jstack pendant cette période a montré que tous les fils étaient bloqués. pstack pendant ce temps, a montré la trace de pile MarkSweep de temps en temps, donc nous ne pouvons pas être sûr à ce sujet aussi bien. L'envoi SIGQUIT n'a donné aucun résultat: Java a jeté la trace de la pile APRES la fin de la période de chargement SYS%.

Nous essayons maintenant de reproduire ce problème avec un petit fragment de code afin que nous puissions demander à Sun.

Si vous savez ce qui le cause, s'il vous plaît laissez-nous savoir. Nous sommes ouverts aux idées et nous sommes désemparés, toute idée est la bienvenue :)

Merci pour votre temps.

Answer 1

Merci à tous pour votre aide.

Finalement, nous avons mis à jour (seulement la moitié des serveurs Java) vers JDK 1.6 et le problème a disparu. Il suffit de ne pas utiliser 1.5.0.10 :)

Nous avons réussi à reproduire ces problèmes en tout accès à des pointeurs nuls (augmente SYS au lieu de nous, et tue le Linux entier.)

Encore une fois, merci à tous.

Answer 2

Avez-vous essayé de profiler des applications. Il existe de bonnes applications de profilage pouvant s'exécuter sur des serveurs de production. Ceux-ci devraient vous donner si le GC rencontre des problèmes et avec quels objets

Answer 3

J'ai eu un problème similaire avec JBoss (JBoss 4, Linux 2.6) l'année dernière. Je pense qu'à la fin, il s'est avéré être lié à un bug d'application, mais c'était vraiment très difficile à comprendre. Je continuerais à essayer d'envoyer un 'kill -3' au processus, pour obtenir une sorte de trace de pile et comprendre ce qui bloque. Peut-être ajouter des instructions de journalisation pour voir si vous pouvez comprendre ce qui le met hors tension. Vous pouvez utiliser 'lsof' pour déterminer quels sont les fichiers ouverts; Cela vous dira s'il y a une fuite de ressources autres que la mémoire.

En outre, pourquoi exécutez-vous JBoss avec -client au lieu de -server? (Pas que je pense que cela aidera dans ce cas, juste une question générale).

Answer 4

Si vous êtes certain que GC est le problème (et il ne son comme elle en fonction de votre description), puis en ajoutant le -XX: + HeapDumpOnOutOfMemoryError drapeau à vos paramètres JBoss pourrait aider (dans JBOSS_HOME/bin/run.conf).

Vous pouvez en savoir plus sur ce drapeau here. Il a été initialement ajouté en Java 6, mais a été plus tard back-ported à Java 1.5.0_07. Fondamentalement, vous obtiendrez un "fichier de vidage" en cas d'erreur OutOfMemoryError, que vous pourrez ensuite ouvrir dans divers outils de profilage. Nous avons eu de la chance avec le Eclipse Memory Analyzer. Cela ne vous donnera pas de réponses «gratuites», mais si vous avez vraiment une fuite de mémoire, alors cela vous aidera à le trouver.

Answer 5

Vous pouvez essayer d'ajouter l'option de ligne de commande -verbose: gc qui devrait imprimer les tailles de GC et de tas sur stdout. Stdout pipe à un fichier et voir si les temps élevés de cpu s'alignent avec un gc majeur. Je me souviens avoir eu des problèmes similaires avec JBoss sous Windows. Périodiquement, le CPU irait à 100%, et l'utilisation de mem mémoire de Windows tomberait soudainement à 2,5 Mo, beaucoup plus petit que possible pour exécuter JBoss, et après quelques secondes se reconstruire. Comme si le serveur entier est tombé et a redémarré lui-même. J'ai finalement suivi mon problème jusqu'à un cache d'instruction préparé n'expirant jamais dans Apache Commons. Si cela semble être un problème de mémoire, vous pouvez commencer à prendre des décharges de tas périodiques et les comparer, ou utiliser quelque chose comme le profileur de mémoire JProbe pour suivre tout.