У меня была постоянная проблема с запуском веб-приложения Tomcat java в док-контейнере (который я называю «задачей» в этом посте), размещенном в ECS (служба эластичных контейнеров) на AWS.
Мы заметили, что задача поднимается до 97% использования ЦП (используя метрики AWS), и хотя иногда она сама по себе снижается до более низкой загрузки ЦП, задача обычно просто закрывается.
К счастью, ECS порождает новую задачу докера и снова запускает приложение (хотя для того, чтобы все вернулось в оперативный режим, требуется 5-10 минут, а это огромное количество времени для нашего производственного дня!)
У нас нет верхнего предела настроенной задачи ECS (возможно, мы должны?) â â в предыдущем проекте мы увеличили ЦП на хосте ECS с 8 виртуальных ЦП до 32 виртуальных ЦП и, конечно же, этот конкретный докер задача постоянно поднималась до 97% ЦП хоста ECS на протяжении всего проекта.
На этой неделе мы увеличили количество ЦП с 8 виртуальных ЦП до 16 виртуальных ЦП (и объем памяти 64 ГБ).
И наблюдают одно и то же. Я увеличил программный предел памяти задачи до 4 ГБ (изначально он был установлен на 2 ГБ), и я вижу, что использование памяти растет, но определенно не превышает 6 ГБ.
Судя по трассировке стека (которая слишком длинная для публикации), приложение tomcat/java не регистрирует ошибок нехватки памяти.
Обычно это начинается с ошибки JDBC (исчерпано максимальное количество соединений/пула), затем происходит отмена регистрации, отключение системы ведения журнала и т. д.
Закрывает ли хост ECS задачу или задача завершает работу после достижения ограничений ЦП/памяти (выключение Java/tomcat)? Кроме того, в нашем журнале агента ECS я вижу заявление о «Выходе 143» — это завершение задачи из ECS или выход самого контейнера? Было бы лучше установить верхний предел ЦП для задачи (относительно памяти JVM, используя все, что ей доступно)?
