tomcat8: 'free(): поврежденные несортированные чанки'
Мы обновились с Ubuntu 16LTS до Ubuntu 18LTS пару дней назад, и с тех пор полностью потерпели крах Apache Tomcat (один раз в день, с интервалом около 25 часов). Процесс Java перестает работать.
На этом этапе к файлу журнала добавляется одна строка:
free(): corrupted unsorted chunks
(это все - нет отметки времени)
Похоже, что это не связано с какими-либо конкретными действиями, происходящими на сервере в то время, по крайней мере, трудно сказать только с двумя случаями, но я подозреваю, что это может иметь какое-то отношение к сбору мусора. Это связано с тем, что мониторинг сервера показывает использование памяти для падения процесса java с 7,90 ГБ до 0,93 ГБ в течение минуты в этот момент (на самом деле процесс Java завершается, поэтому возможно, что меньшее количество будет после того, как я вручную перезапустил tomcat). Максимальная настройка памяти сервера -Xmmx установлена на 8 ГБ, и постепенно перед сбоем она увеличивалась до уровня чуть ниже, чем в течение дня.
Кроме того, самые первые строки журнала Tomcat являются
NOTE: Picked up JDK_JAVA_OPTIONS: --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
В /etc/default/tomcat8
У меня есть линия
JAVA_OPTS="-Djava.awt.headless=true -Xmx8g -XX:+UseConcMarkSweepGC"
Эта опция UseConcMarkSweepGC была добавлена обратно в Ubuntu 16, где использовался tomcat7, и я, кажется, помню, что это было рекомендовано. На самом деле конфиг. файл все еще говорит
'Use "-XX:+UseConcMarkSweepGC" to enable the CMS garbage collector (improved response time)
Во всяком случае, теперь я удалил его в надежде, что это проблема. Посмотрим, случится ли сбой завтра, но покажется ли это разумным? Может ли кто-нибудь предложить какие-либо шаги для проверки этой гипотезы или дальнейшей отладки, или какие-либо другие идеи относительно того, что может происходить?
1 ответ
В случае, если у кого-то еще есть эта проблема, благодаря полезному списку рассылки java-core-libs, я обнаружил, что причиной было использование библиотек APR/native в Tomcat. Удаление их (apt-get remove libapr1) и удаление ссылок на конфигурацию из server.xml решило проблему