【问题标题】:How to capture on-JVM-exit heap dumps without affecting the ECS service?如何在不影响 ECS 服务的情况下捕获 on-JVM-exit 堆转储?
【发布时间】:2019-07-31 14:02:31
【问题描述】:

我基于 JVM 的应用程序在 Amazon ECS 上运行。在某些我无法在测试环境中重现的情况下,它会因 OutOfMemoryError 而崩溃。我想捕获 JVM 堆转储(使用 HeapDumpOnOutOfMemoryError)以查看发生了什么。但是有一个问题——因为我的应用程序使用了大量内存,堆转储需要很长时间,并且 ECS 会杀死中间的容器,因为健康检查失败。我最终得到了一个无法使用的截断转储文件。

我可以通过更改健康检查配置来获得正确的堆转储,但这可能会影响 ECS 服务,因为如果没有良好的健康检查,集群可能会运行无响应的实例。

我正在寻找一种方法,它可以让我自动捕获堆转储,而对生产集群的影响最小。

【问题讨论】:

    标签: amazon-ecs


    【解决方案1】:

    这是围绕 Fargate 实例还是 EC2?

    在任何一种情况下,您都可以在同一个集群中添加一个 EC2 实例,并且该节点即使在任务失败时也能够登录到主机并获取堆转储。

    【讨论】:

    • 请仔细阅读我的问题并注意 1) 我想要一个自动化的解决方案 2) JVM 堆转储花费的时间超过 ECS 想要等待的时间,然后终止中间的堆转储进程,导致转储损坏.因此,遗憾的是,仅登录到主机不会削减它。
    【解决方案2】:

    我找到的方式:

    1. 准备一份您的 ECS 服务 (Service2) 的副本,除了:
      • 健康检查设置(禁用健康检查)
      • HeapDumpOnOutOfMemoryError JVM 选项(启用)
      • 节点数(设置为 1)
    2. 让 Service2 与现有 Service1 一起处理生产流量(例如,通过将流量转发到 Service1 和 Service2 的负载平衡器路由 HTTP 流量)
    3. 等到Service2的ECS任务所在的节点产生JVM堆转储
    4. 将 Service2 缩减到零节点

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2016-08-28
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-05-24
      • 1970-01-01
      • 1970-01-01
      • 2013-11-03
      相关资源
      最近更新 更多