Почему ограничения при запуске .sh не работают.

[SawaPlayGO]

У меня есть два сервера в связке велосити:

- Прокси сервера (Velocity)
- Основной сервер (Papper 1.16.5)

Параметры запускатора такие:

Для основного сервера:

java16 -Xms16384M -Xmx16384M --add-modules=jdk.incubator.vector -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true -XX:G1NewSizePercent=40 -XX:G1MaxNewSizePercent=50 -XX:G1HeapRegionSize=16M -XX:G1ReservePercent=15 -jar server.jar --nogui

Для velocity сервера:

java -Xms2048M -Xmx2048M -XX:+UseG1GC -XX:G1HeapRegionSize=4M -XX:+UnlockExperimentalVMOptions -XX:+ParallelRefProcEnabled -XX:+AlwaysPreTouch -XX:MaxInlineLevel=15 -jar server.jar

Получается нагрузка чистой OC (Ubuntu 22.04.4 LTS (amd64)) в начале (без запуска серверов) составляет:

Вам необходимо зарегистрироваться для просмотра изображений-вложений

После того как включил сервер velocity:

Вам необходимо зарегистрироваться для просмотра изображений-вложений

Включаю основной сервер (Papper 1.16.5)

Вам необходимо зарегистрироваться для просмотра изображений-вложений

После я час специально с человеком играл на сервере (там располагается самописная мини - игра). После чего оперативная память забивается под завязку именно на пк. И в следствии чего вся система ложиться.

Вот скрин с ClearLagg (только стартанул сервер):

Вам необходимо зарегистрироваться для просмотра изображений-вложений

Отчёт метрики плагина spark:

Авторизуйтесь для просмотра ссылок.

- если ссылка не работает, можно скринами:

Вам необходимо зарегистрироваться для просмотра изображений-вложений

Вам необходимо зарегистрироваться для просмотра изображений-вложений

Вам необходимо зарегистрироваться для просмотра изображений-вложений

Весь список плагинов которые используются:

BlueSlimeCore, Chatty, ClearLag, CTFFight (самописный), EasySetSpawn*, Essentials, ExploitFixer, HamsterAPI, HideStream*, LuckPerms, PlaceholderAPI, RespawnX, spark, TAB, ViaVersion, WorldEdit, WorldGuard

В моём представлении да и при запуске сервера, он сразу отхватывает себе кусок памяти выделенный запускатором и пользуется только им, по сути не должен трогать не зарезервированную для него память, а пользоваться своей, по сути там она не забивается (все 16 гб не реализованы), но почему-то ограничители не работают из-за чего серверные процессы начинаю кушать лишнее.

Может дело в оптимизирующих флагах, их я брал тут:

Авторизуйтесь для просмотра ссылок.

Так же вот скрины с полностью забитой оперативой:

Вам необходимо зарегистрироваться для просмотра изображений-вложений

Скрин со spark:

Вам необходимо зарегистрироваться для просмотра изображений-вложений

 

[HomaPlus]

но почему-то ограничители не работают из-за чего серверные процессы начинаю кушать лишнее.

Xms2048M задает максимальный размер кучи, а не процесса. Вот и вся разница.
Память jvm ограничивается не только кучей.

Если ты хочешь ограничить системные ресурсы для приложения - используй докер, ну и что-то, что будет поднимать докеры, если последние здохнут (обычно для этого используют кубернетес, но в малых масштабах оно не надо, можно самому накостылять)

Дело в каком-то кривом плагине скорее всего

offtop

К слову, я тоже любитель по-баловаться Unsafe оптимизацией, но в случае с майном в этом обычно нет нужды

 

[Feniksovich]

Как уже упомянули выше, память JVM – это далеко не только куча (heap), формально всю область используемой памяти можно поделить на heap и non-heap, второй включает в себя Metaspace (придерживаясь спецификации Java 8+) и много чего еще, который с кучей ничего общего не имеет. Когда приложение начинает использовать заметно больше памяти, чем было выделено для кучи (флагами -Xms, -Xmx), то становится очевидно, что растет non-heap.

Исходя из отчетов spark – утилизация памяти в куче не достигает и 50% от выделенного и размер non-heap в несколько раз превышает размер heap, что не норма. Скорее всего какой-то плагин лезет в память вне кучи – это можно делать по разному – и гадит там. Можно анализировать потребление памяти в VisualVM, YourKit, JProfiler или еще где-нибудь.

 

[HomaPlus]

Как уже упомянули выше, память JVM – это далеко не только куча (heap), формально всю область используемой памяти можно поделить на heap и non-heap, второй включает в себя Metaspace (придерживаясь спецификации Java 8+) и много чего еще, который с кучей ничего общего не имеет. Когда приложение начинает использовать заметно больше памяти, чем было выделено для кучи (флагами -Xms, -Xmx), то становится очевидно, что растет non-heap.

Исходя из отчетов spark – утилизация памяти в куче не достигает и 50% от выделенного и размер non-heap в несколько раз превышает размер heap, что не норма. Скорее всего какой-то плагин лезет в память вне кучи – это можно делать по разному – и гадит там. Можно анализировать потребление памяти в VisualVM, JProfiler или еще где-нибудь, spark ничего не говорит про тот же Metaspace.

Ни VisualVM, ни JMC ни Intelij профайлер не умеют анализировать потребление offheap.

Полный анализ не возможен, максимум можно предполагать откуда оно набегло.

Если у кого-то есть желание проверить YourKit на эту тему - буду благодарен, на счет остальных надежды вообще не питаю

 

[Feniksovich]

Ни VisualVM, ни JMC ни Intelij профайлер не умеют анализировать потребление offheap.

Полный анализ не возможен, максимум можно предполагать откуда оно набегло.

Если у кого-то есть желание проверить YourKit на эту тему - буду благодарен, на счет остальных надежды вообще не питаю

Да, исходя из документации YourKit есть возможность просто мониторить общее потребление, под "анализировать" я скорее всего это и имел ввиду: «Unfortunately, the only information JVM provides on non-heap memory is its overall size. No detailed information on non-heap memory content is available». В этой ситуации с набором метрик от spark и без этих инструментов все очевидно.

 

[SawaPlayGO]

Если ты хочешь ограничить системные ресурсы для приложения - используй докер, ну и что-то, что будет поднимать докеры, если последние здохнут (обычно для этого используют кубернетес, но в малых масштабах оно не надо, можно самому накостылять)

Если я буду использовать ограничители на отдельное приложение (сервер) он не будет превышать лимитов зарезервированных заранее в установленном отдельно ограничители? На сервер будет влияние внутри, ведь если он не может брать доп память какие-то процессы не смогут выполняться или он переориентируется на свободную выделенную внутри сервера память (heap)?

 

[HomaPlus]

Если я буду использовать ограничители на отдельное приложение (сервер) он не будет превышать лимитов зарезервированных заранее в установленном отдельно ограничители? На сервер будет влияние внутри, ведь если он не может брать доп память какие-то процессы не смогут выполняться или он переориентируется на свободную выделенную внутри сервера память (heap)?

Тут уже ответили 2-жды. Флаги не ограничивают потребление памяти для процесса.

Либо перебирай сборку, чтобы найти утеччку offheap, а потом фикси это (могу лично найти и исправить ошибку, благо есть опыт отлова утечек offheap, но тебе придется расплатиться телефоном)
Либо запихивай в докер, и поднимай сервер каждый раз, когда он упадет из-за перерасхода оперативки