Помощь 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 стабильно работает, а другие пользователи не жалуются