1

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

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

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

4

2 回答 2

1

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

这是我建议诊断的内容：

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

祝你好运。希望有帮助。

于 2012-08-07T09:17:09.390 回答
0

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

于 2015-04-23T01:43:49.783 回答