Помощь oom kill от контейнера и джавы

Версия ядра сервера

1.21+

Сервер хорошо работает со своей памятью, но со временем она забивается контейнером и джавой, что приводит к oom kill. Как можно собрать информацию о вероятных утечках и после чего исправить их?

 

Чтобы собрать информацию о возможных утечках памяти в Java-приложении, вы можете использовать несколько методов и инструментов. Вот некоторые шаги, которые помогут вам диагностировать проблему:

1. Использование Java VisualVM:
- Java VisualVM — это инструмент, который позволяет мониторить производительность Java-приложений и анализировать использование памяти.
- Запустите ваше приложение с параметром -Dcom.sun.management.jmxremote, чтобы включить JMX.
- Подключитесь к вашему приложению через VisualVM и просмотрите использование памяти, а также сделайте дампы памяти.

2. Сбор дампов памяти:
- Вы можете настроить ваш сервер для создания дампов памяти при возникновении OOM (Out of Memory) ошибки.
- Для этого добавьте следующие параметры при запуске Java-приложения:

     -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump

- После сбоя вы сможете проанализировать дамп памяти с помощью инструментов, таких как Eclipse Memory Analyzer (MAT).

3. Использование профилировщиков:
- Инструменты, такие как YourKit или JProfiler, могут помочь вам в профилировании приложения и выявлении утечек памяти.
- Эти инструменты предоставляют детализированную информацию о том, какие объекты занимают память и как они связаны между собой.

4. Анализ кода:
- Проверьте код на предмет неправильного использования коллекций, неосвобожденных ресурсов (например, потоков, соединений), а также на предмет статических ссылок на объекты, которые могут препятствовать их сборке мусора.

5. Логирование:
- Добавьте логирование, чтобы отслеживать создание и уничтожение объектов, особенно тех, которые могут потреблять много памяти.

После сбора информации и анализа дампов памяти, вы сможете выявить проблемные места и внести необходимые изменения в код для устранения утечек памяти.

 

Чтобы собрать информацию о возможных утечках памяти в Java-приложении, вы можете использовать несколько методов и инструментов...

К слову, хост панелька - ряд методов может быть ограничен

 

К слову, хост панелька - ряд методов может быть ограничен

Через спарк можно если не ошибаюсь вот так

/spark heapsummary
/spark gc
/spark tickmonitoring --threshold (время)

 

Через спарк можно если не ошибаюсь...

heapsummary - spark
profiler - spark
С тпс проблем нет, фризов тоже не наблюдается.

 

Посмотреть вложение 74589Посмотреть вложение 74590Посмотреть вложение 74591
heapsummary - spark
profiler - spark
С тпс проблем нет, фризов тоже не наблюдается.

Профайлер "No data"


AuraSkills тащит свой внутренний SnakeYAML и держит тысячи ResolverTuple объектов. 91k org.yaml.snakeyaml.error.Mark это скорее всего YAML-парсер который не освобождает объекты после разбора конфигов. Наверное вызываеться при каждном reload/обновлении скиллов игрока.

​

​

LPX обфусцированный код с 10k экземпляров o0 класса и 22k KeyImpl. он тащит свои копии PacketEvents и Adventure внутрь себя.


OOM скорее всего не от heap Java занимает 847 MB из 1.8 GB выделенных, это нормально. Убивает процесс из-за того что весь хост под завязку 177 GB из 187 GB. Либо слишком много серверов рядом, либо native память JVM выходит за пределы heap, сложно сказать точно.

 

Профайлер "No data"

spark

spark is a performance profiler for Minecraft clients, servers, and proxies.

spark.lucko.me

AuraSkills

Можно и нужно ли что-либо с этим делать?

LPX

Сбм

OOM скорее всего не от heap Java занимает 847 MB из 1.8 GB выделенных, это нормально. Убивает процесс из-за того что весь хост под завязку 177 GB из 187 GB

Разве это не вызвало бы проблем с p####i на том же хостинге, или у других клиентов хостинга? Ибо p####i стабильно работает, а другие пользователи не жалуются

 

spark

spark is a performance profiler for Minecraft clients, servers, and proxies.

spark.lucko.me

Можно и нужно ли что-либо с этим делать?

Сбм

Разве это не вызвало бы проблем с p####i на том же хостинге, или у других клиентов хостинга? Ибо p####i стабильно работает, а другие пользователи не жалуются

Мне все еще нужен рабочий профайлер

 

Мне все еще нужен рабочий профайлер

Что не так? У меня он работает

 

Что не так? У меня он работает

 

Посмотреть вложение 74623

Интересно однако получается

 

Посмотреть вложение 74623

spark Попробуй эту

 

spark Попробуй эту

попробуйте перед MaxRAMPercentage добавить -Xms128M

Вот мои аргументы:

java -Xms128M -XX:MaxRAMPercentage=95.0 -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 --add-modules=jdk.incubator.vector -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -XX:+AlwaysActAsServerClassMachine -XX:+UseFMA -DLeaf.enableFMA=true -DLeaf.disable-vanilla-profiler=true -Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true -jar server.jar

 

добавить -Xms128M

Пробовал - ничего не изменилось

Вот мои аргументы:

Запустился на них - проблема увы не исчезла

 

Пробовал - ничего не изменилось

Запустился на них - проблема увы не исчезла

Вероятно всего где-то утечка памяти как вариант

Нужно сделать
heapsummary
и
profiler
на пике нагрузки сервера

 

Для сервера на 1 21 11 это мало...
тем более вижу есть не мало плагинов
Вот например нагрузка моего сервера с уже прогруженым миром и 0 онлайном



Это с учетом G1GC, в вашем случае 5 гб это маловато, сборщик жрет свое так еще и плагинов есть не мало.

При каком онлайне сервер уже начинает падать?

 

Посмотреть вложение 74651
Для сервера на 1 21 11 это мало...
тем более вижу есть не мало плагинов
Вот например нагрузка моего сервера с уже прогруженым миром и 0 онлайном

Посмотреть вложение 74652

Это с учетом G1GC, в вашем случае 5 гб это маловато, сборщик жрет свое так еще и плагинов есть не мало.

При каком онлайне сервер уже начинает падать?

Ранее подобного поведения не было. В панели использование озу было 2-3гб. Что касается онлайна - потребление озу растет даже от одного игрока, хоть и медленно. Что касается плагинов - их действительно много (69), но нет каких-либо сомнительных ресурсов

 

profiler

spark

spark is a performance profiler for Minecraft clients, servers, and proxies.

spark.lucko.me

heapsummary

spark

spark is a performance profiler for Minecraft clients, servers, and proxies.

spark.lucko.me

 

spark

spark is a performance profiler for Minecraft clients, servers, and proxies.

spark.lucko.me

spark

spark is a performance profiler for Minecraft clients, servers, and proxies.

spark.lucko.me

Стоит попробовать изменить ядро Leaf все таки только недавно вышел в stable 1.21.11
Могу перенести сервер на свою VPS с панелью с таким же оборудованием выделив 14 GB оперативной памяти что бы наверняка узнать в чем проблема.

 

Попытки лечить OOM Killer поиском утечек в плагинах при MaxRAMPercentage=95.0 - это сильно.

 

Попытки лечить OOM Killer поиском утечек в плагинах при MaxRAMPercentage=95.0 - это сильно.

И что ты предлагаешь?

 

И что ты предлагаешь?

Предлагаю для начала не ставить флаги, назначение которых ты не знаешь. Уменьшай MaxRAMPercentage до 70.0-65.0. Тебе нужно пространство под метаспейс и нативные буферы, а не илюзия бесконечной кучи.

 

Предлагаю для начала не ставить флаги, назначение которых ты не знаешь. Уменьшай MaxRAMPercentage до 70.0-65.0. Тебе нужно пространство под метаспейс и нативные буферы, а не илюзия бесконечной кучи.

Как раз таки куча чистится, судя по мониторингу .jfr. Хотя я включал его на 10м после запуска сервера, не факт что он подтянул всё. Что касается MaxRAMPercentage - ставил разные варианты, включая 70 - результат всё тот же

 

Как раз таки куча чистится, судя по мониторингу .jfr. Хотя я включал его на 10м после запуска сервера, не факт что он подтянул всё. Что касается MaxRAMPercentage - ставил разные варианты, включая 70 - результат всё тот же

При чём тут вообще чистая куча в контексте OOM Killer? Ты путаешь потребление внутри кучи и RSS всего процесса.

 

При чём тут вообще чистая куча в контексте OOM Killer?

Выше была упомянута иллюзия бесконечной кучи

Ты путаешь потребление внутри кучи и RSS всего процесса.

Как можно будет глянуть потребление последнего?