AWS의 ECS(탄력적 컨테이너 서비스)에서 호스팅되는 도커 컨테이너(이 게시물에서 '작업'이라고 함)에서 Tomcat Java 웹 애플리케이션을 실행하는 데 지속적인 문제가 있었습니다.
작업이 97% CPU 사용량(AWS 지표 사용)으로 올라가고 때로는 자체적으로 더 낮은 CPU 사용량으로 다시 내려가지만 일반적으로 작업이 종료됩니다.
운 좋게도 ECS는 새로운 도커 작업을 생성하고 애플리케이션을 다시 시작합니다(그러나 모든 것이 다시 온라인 상태가 되는 데 5-10분이 걸리며 이는 프로덕션 하루 동안 엄청난 시간입니다!)

구성된 ECS 작업에 상한선이 없습니다(아마도 해야 합니까?) — — 이전 프로젝트에서 ECS 호스트의 CPU를 8 vCPU에서 32 vCPU로 늘렸고 이 특정 도커 작업이 ECS의 97%는 프로젝트 전반에 걸쳐 지속적으로 CPU를 호스트합니다.

이번 주에 CPU를 8 vCPU에서 16 vCPU(메모리 64GB)로 늘렸습니다.
그리고 같은 것을 보고 있습니다. 작업의 소프트 메모리 제한을 4GB(원래 2GB로 설정)로 늘렸고 메모리 사용량이 증가하는 것을 볼 수 있지만 확실히 약 6GB를 넘지 않습니다.

스택 추적(게시하기에는 너무 깁니다)을 보면 tomcat/java 애플리케이션에서 기록하는 메모리 부족 오류가 없습니다.
일반적으로 JDBC 오류(최대 연결/풀 소진)로 시작한 다음 등록이 취소되고 로깅 시스템이 종료되는 등의 문제가 발생합니다.

ECS 호스트가 작업을 종료하고 있습니까, 아니면 CPU/메모리 제약 조건에 도달한 후 작업이 자체적으로 종료됩니까(java/tomcat이 자체적으로 종료됨)? 또한 ECS 에이전트 로그에서 'Exit 143'에 대한 설명을 볼 수 있습니다. ECS에서 작업을 종료하는 것입니까 아니면 컨테이너 자체에서 종료하는 것입니까? 작업에 대해 CPU 상한을 설정하는 것이 가장 좋습니까(JVM 메모리와 관련하여 사용 가능한 모든 것을 사용)?

no answer