如何捕获Amazon EBS上的OutOfMemory错误（Elastic BeanStalk）

Question

对于你来说，这是一个棘手的问题 - 我们有一个Java Web应用程序，部署在Amazon ElasticBeanStalk上的Tomcat Web服务器上。并且我们认为我们有内存泄漏b / c似乎JVM每晚都会因OutOfMemory异常而崩溃。问题是在崩溃之后，EBS会自动废弃旧的EC2实例并启动一个新的实例。所有日志和信息也被废弃了......

我现在正在开发一个自定义CloudWatch指标来监视JVM的内存（你会认为应该有一个准备好的...）但这不会帮助我生成堆转储

有没有人遇到类似的问题，知道如何在EBS上捕获这些错误？

Answer 1

这听起来像是不寻常的EC2（不是EBS）实例行为。有趣的是，如果Tomcats摔倒，那么机器实例会受到影响（就停止或终止而言）。

这是我建议诊断的：

1. 获取正在运行的实例读取以检查/播放
2. 看一下“终止保护” - 这是否设置为“启用” - 这可以解释问题的“报废”部分（如果通过报废则表示实例终止并被删除）。您可以使用AWS控制台在EC2实例的属性中找到它。
3. 看一下Tomcat服务器配置的Java内存设置。也许虚拟机的最大值（Xmx）更大！？如果是这样，也许Tomcat实际上是在内存中运行机器，这可以解释一些EC2对内存不足的响应。我假设你的意思是“停止”而不是“报废”，否则你怎么知道你的内存不足错误？
4. 如果您在工作实例上手动终止tomcat / java进程，该实例是否仍然可以运行（或者您是否已启动并且实例已停止）？如果因为你停止tomcat而发生了某些事情，那就意味着一些监控过程正在开始并明确地取下机器。
5. 使用-XX：-HeapDumpOnOutOfMemoryError生成转储文件 - 这将帮助您确定泄漏的位置并希望解决根本原因。

祝好运。希望有所帮助。

Answer 2

考虑像Sumologic这样的日志收集服务。您指定的日志文件将被收集并可在线进行分析。因此，即使您的EC2实例被替换，您也可以进行取证以查看它们发生了什么