J'ai une application exécutée sur WebSphere Application Server 6.0 et il se bloque presque tous les jours en raison de la mémoire de mémoire. De Verbose GC est certain qu'il y a les fuites de mémoire (nombre d'entre elles)
Malheureusement, l'application est fournie par le fournisseur externe et que les choses que les objets sont fixes est un processus lent et douloureux. Dans le cadre du processus, j'ai besoin de rassembler les bûches et les tasques de mesure chaque fois que l'OMM se produit.
Maintenant, je cherche un moyen de l'automatiser. Un problème fondamental est de savoir comment détecter la condition OOM. Une solution serait de créer un script shell qui recherchera périodiquement des nouveaux heapdumps. Cette approche me semble un peu sale. Une autre approche pourrait être de tirer parti de la JMX d'une manière ou d'une autre. Mais j'ai peu ou pas d'expérience dans cette région et n'avez pas beaucoup d'idée de la façon de le faire.
ou est dans une sorte de déclencheur / crochets pour cela? Merci beaucoup pour tous les conseils!
9 Réponses :
Vous pouvez transmettre les arguments suivants à la JVM lors du démarrage et un dépotoir de tas sera automatiquement généré sur un OutofMemoryError. Le deuxième argument vous permet de spécifier le chemin du fichier de vidage du tas. En utilisant cela au moins, vous pouvez vérifier l'existence d'un fichier spécifique pour voir si un dépotoir de tas est survenu.
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<value>
Merci. J'utilise cela, mais j'ai besoin d'une sorte de notification que Heapdump a été créée. Et je cherche une meilleure approche que de numériser périodiquement le système de fichiers.
J'ai mis à jour ma réponse afin que vous n'ayez besoin que de rechercher l'existence d'un fichier spécifique. Je ne suis pas sûr qu'il y ait une meilleure approche.
Utilisez simplement quelque chose comme ça pour vous informer: -XX: ONOUTOFMEMORYERROR = "ECHO PID% P vient de générer un heapdump | mail admin@admin.com" pour vous mail ou exécuter la commande que vous souhaitez notifier.
et alternative à attendre jusqu'à ce que l'application se bloque peut être de scripter un redémarrage contrôlé comme chaque nuit si vous êtes optimiste qu'il peut survivre pendant douze heures.
Peut-être même WebSphere peut le faire pour vous!
Eh bien, cela m'aiderait à court terme. D'une autre main, je dois avoir les fuites fixes. Et cette approche m'empêcherait de rassembler les bûches lorsque l'OMM se produit.
Ahh, je pensais que vous deviez juste attendre que votre fournisseur externe ait corrigé les problèmes ... Bien sûr, si vous avez besoin des décharges de hachage pour les reportings qu'il ne s'agit d'une histoire différente :)
Vous pouvez ajouter une classe d'écouteurs (session ScOPed ou d'attributateurs d'attributs d'application) qui seraient appelé chaque fois qu'un nouvel objet est ajouté dans la portée de la session / de l'application.
Dans cela - vous pouvez tenter de vérifier la mémoire totale utilisée par l'application (Journal de journal), car étant donné que l'appel GC GC (Notez que l'invoquer cela n'imposera pas que GC fonctionnera toujours)
(Ce qui précède est pour la pièce de journalisation et GC basé sur la croissance d'utilisation)
pour GC programmé: De plus, vous pouvez conserver une classe de tâches de minuterie qui fonctionne après chaque heure et une demande de GC.
Merci pour votre réponse. Malheureusement, exécutant GC ne vous aide pas s'il ya les fuites de mémoire (= références indésirables aux objets) des graphiques Verbose GC, je peux voir que le capteur de déchets est déclenché très souvent avant l'OMOM.
Dans ce cas, si vous êtes au courant des objets supplémentaires, vous n'utilisez pas d'objets actifs, vous pouvez les supprimer de la portée (application / session) après une période définie.
Avez-vous regardé JConsole ? Il utilise JMX pour vous donner la visibilité d'une variété de métriques JVM, y compris des informations de mémoire. Cela mérairierait probablement de surveiller votre demande à l'aide de cela pour commencer, pour obtenir une idée de la façon dont la mémoire est consommée. Vous trouverez peut-être que la mémoire est consommée de manière uniforme au cours de la journée ou lorsque vous utilisez certaines fonctionnalités.
Jetez un coup d'œil à la Détection de la mémoire basse mémoire de la liaison ci-dessus.
Si vous avez besoin que vous puissiez, écrivez un client JMX < / a> Pour regarder l'application automatiquement et déclencher toutes les actions requises. JConsole indiquera les méthodes JMX dont vous avez besoin pour sonder.
Je vois deux options si vous voulez dumping de tas automatisé mais @ La solution de Mark avec vidage de tas sur OOM n'est pas satisfaisante.
MemoryMXBean pour détecter une pression de mémoire élevée, puis Créer par programme par programme si l'utilisation (ou l'utilisation du delta) semble élevée.
jmap (fonctionne à la fois localement et à distance).
Ce serait bien si vous pouviez avoir un rappel sur OOM, mais que, UHM, ce rappel serait probablement bloqué avec une erreur d'OOM. :)
Avez-vous consulté l'outil Jvisalvm dans la dernière Java 6 JDK's?
C'est génial d'inspecter le code de course.
Je vais contester que vous avez besoin des décharges de tas lorsque l'OMM survient. La collecte périodique des informations au fil du temps devrait donner la photo de ce qui se passe.
Comme a été observé divers outils existent pour analyser ces problèmes. J'ai eu du succès avec ITCAM pour WebSphere, comme Ibmer, j'ai accès à cela. Nous avons été très rapidement capables d'identifier les lignes de code exactes dans la situation des problèmes.
Si vous pouvez obtenir un outil de cette nature, alors c'est la voie à suivre.
Notre expérience avec ITCAM a été inférieure à celle de la perspective de surveillance. Nous l'avons jeté en faveur de l'introscope CA Wily.
Il devrait être possible d'écrire un programme simple pour obtenir la liste de processus du noyau et d'analyser pour voir si votre processus était toujours en cours d'exécution. Sur une boîte Unix, vous pourriez probablement préparer quelque chose à Perl dans quelques minutes (si vous connaissez Perl), je ne sais pas à quel point il serait difficile sous Windows. Exécutez-le comme une tâche planifiée toutes les cinq minutes environ, et si le processus ne s'affiche pas, vous pourriez avoir une fourchette d'un autre processus qui traiterait du dépotoir du tas et de redémarrer était.