AWS ECS Task内存溢出场景CloudWatch告警配置及问题解决咨询

• 首先开启ECS CloudWatch Container Insights，开启后会自动上报单Task维度的内存指标，包含TaskArn、所属集群、所属服务等筛选维度，可拿到每个Task独立的MemoryUtilization（内存使用率）、MemoryUsed（内存使用量）数据，解决服务级平均指标无法覆盖单Task异常的问题
• 配置告警时，选择ECS Container Insights分类下的MemoryUtilization指标，统计方式选Maximum，维度筛选你对应的集群和服务，告警触发规则设置为任意一个指标实例超过阈值，阈值建议设置为90%（对应16GB内存配置即14.4GB，预留足够缓冲），监控周期设为1分钟即可
• 若需精准匹配OOM导致的Task停止事件，可额外配置EventBridge规则：匹配ECS任务状态变更事件，筛选停止原因包含OOMKilled或OutOfMemoryError的事件，直接关联告警通知，该方案不会出现高内存但未崩溃的误报场景

• 先做峰值内存压测：拉取历史出现OOM的任务对应的数据量，压测得到处理峰值数据量所需的最小内存，将Task硬内存限制上调至压测峰值的1.2倍以上，避免硬限制触发内核OOM Killer直接终止进程
• 配置弹性内存限制：在ECS任务定义中设置memoryReservation（软内存限制）为14GB，memory（硬内存限制）根据压测结果设置为20~24GB，正常调度时按软限制分配资源，峰值时允许任务使用到硬限制，兼顾集群资源利用率和抗波动能力
• 应用层面优化：如果是Java类应用，添加JVM参数-XX:MaxRAMPercentage=75，避免JVM堆内存占用过高导致堆外内存不足触发OOM；其他语言应用也建议设置应用自身的内存上限，预留至少25%的内存给系统进程开销
• 动态规格调度：如果不想统一调高所有Task的内存配置，可以在Task启动前先预判本次处理的数据量，根据数据量大小动态选择对应内存规格的任务定义（小数据量用16GB，大数据量用32GB），兼顾成本和稳定性

内容的提问来源于stack exchange，提问作者dapo