1. Accueil
  2. Question et réponse
  3. Comment faire pour attraper les erreurs OutOfMemory sur Amazon EBS

Comment faire pour attraper les erreurs OutOfMemory sur Amazon EBS

2012-08-07 2 views
1

Voici une question délicate pour vous - Nous avons une application Web Java, déployée sur les serveurs Web Tomcat sur Amazon EBS. et nous pensons que nous avons une fuite de mémoire b/c il semble que la JVM se bloque tous les soirs avec l'exception OutOfMemory. Le problème est qu'après le crash, EBS annule automatiquement l'ancienne instance EC2 et en démarre une nouvelle. Je suis en train de développer une métrique CloudWatch personnalisée pour surveiller la mémoire de la JVM (on pourrait penser qu'il devrait y en avoir une préparée ...) mais cela n'aidera pas moi générer des décharges tasComment faire pour attraper les erreurs OutOfMemory sur Amazon EBS

Est-ce que quelqu'un a traversé un problème similaire et sait comment attraper ces erreurs sur EBS?

Source

2012-08-07 Sharon Ben Asher

+2

EBS est le service de stockage. Comment cela est-il pertinent pour les problèmes de mémoire? –

+0

Je sens que votre problème n'est pas clair. Nous avons aussi nos serveurs Tomcat sur Amazon EBS, et j'ai vu une erreur de mémoire insuffisante, mais l'erreur ne plante que tomcat et n'a aucun effet sur l'instance EC2. Considérez votre instance EBS comme un serveur normal. Un crash dans tomcat ne redémarrera jamais la machine. – Kamal

+1

EBS est le haricot élastique, pas le service de stockage (S3). Une partie des fonctionnalités d'EBS est l'équilibrage de charge automatique où vous définissez des instances min et max qui sont automatiquement démarrées et terminées en fonction du trafic actuel. le nombre minimum d'instances ne peut pas être inférieur à 1, donc si vous avez une instance en cours d'exécution et que tomcat cesse de répondre aux demandes HTTP, EBS mettra automatiquement fin à l'instance EC2 et en démarrera une nouvelle. n'est-ce pas la caractéristique la plus fondamentale d'EBS? –

Répondre

0

Cela ressemble certainement à un comportement inhabituel d'instance EC2 (pas EBS). Il est intéressant de savoir que si Tomcats tombe, l'instance de la machine est affectée (en termes d'arrêt ou de fin).

C'est ce que je suggère à diagnostiquer:

  1. obtenir une instance en cours d'exécution lu pour examiner/jouer avec
  2. un coup d'oeil à la « protection de résiliation » - est cet ensemble de « permis » ou pas - cela pourrait expliquer la partie "mise au rebut" de votre problème (si par scrappage, vous voulez dire que l'instance se termine et est supprimée). Vous pouvez le trouver dans les propriétés de votre instance EC2 à l'aide de la console AWS.
  3. jetez un coup d'œil aux paramètres de la mémoire Java avec lesquels votre serveur Tomcat est configuré. Peut-être que le max est (Xmx) plus grand que la machine virtuelle!? Si tel est le cas, Tomcat exécute littéralement la mémoire de la machine, ce qui pourrait expliquer une partie de la réponse EC2 à votre manque de mémoire. Je suppose que vous voulez dire "arrêté" plutôt que "mis au rebut" sinon comment sauriez-vous que vous obtenez une erreur de mémoire?
  4. Si vous tuez manuellement le processus tomcat/java sur une instance de travail, l'instance reste-t-elle opérationnelle (ou est-ce que vous êtes démarré et l'instance est arrêtée)? Si quelque chose se produit simplement parce que vous arrêtez Tomcat, cela signifie qu'un processus de surveillance est en train de démarrer et d'arrêter la machine explicitement. Utilisez le -XX: -HeapDumpOnOutOfMemoryError pour produire un fichier de vidage - cela vous aidera à déterminer où votre fuite est et, espérons-le, corrigera la cause première.

Bonne chance. J'espère que cela pourra aider. Considérons un service de collecte de journaux tel que Sumologic.

Source

2012-08-07 09:17:09

+0

salut jowierun, désolé pour la réponse tardive. C'est un problème EBS, pas EC2 (voir mon commentaire sur le post de question, l'équilibrage de charge d'EBS est le «processus de surveillance» auquel vous faites référence.elle fonctionne sur EC2 mais est responsable de la "scrapping" de l'instance et du démarrage) nous n'avons jamais résolu le problème de scrapping des instances, mais nous avons corrigé le problème outofmemory en remplaçant openjdk par hotspot et en le mettant à jour vers le dernier AWS SDK. je vais regarder "Protection contre les terminaisons" et tuer manuellement le tomcat –

0

Les fichiers journaux que vous spécifiez sont collectés et disponibles pour analyse en ligne. Donc, même si vos instances EC2 sont remplacées, vous pouvez faire des analyses pour voir ce qui leur est arrivé

Source

2015-04-23 01:43:49 Sco

Questions connexes

 Questions connexes