Рискну предположить, что подобное поведение может быть вызвано утечкой памяти и, соответственно, потугами бомжа Валеры (Garbage Collector) ее освободить (почти всегда JVM сделает вызов к GC, прежде чем вывалит OOME).
Вам необходимо зарегистрироваться для просмотра изображений-вложений
Есть возможность как-нибудь получить график использования ОЗУ во время работы?
+ Не помешает дамп кучи без GC и с предварительно вызванным GC:
Выполнить
/spark heapsummary в момент максимального использования ОЗУ, если таковой имеется.
Выполнить
/spark heapsummary --run-gc-before (через минут 5 после использования первой команды).
Мониторить использование памяти можно через
/spark healthreport --memory.
- - - UPD:
1. Периодичность падения TPS также наводит на мысль об утечках памяти и работе GC.
2. Заметил, что ты используешь Pterodactyl, но график использования памяти там слишком урезанный и он не подойдет для полноценного анализа, только если ловить момент с пиками и падениями.
3. Поскольку сборка с говносайта, да еще и с nulled плагинами различными, то почему бы и не утечки.
4. Кто посоветовал использовать Serial Collector?... Размер кучи, судя по флагам запуска, огромен, порядка 10 GB. Использование Serial GC в этом случае — самоубийство.
Пробуем менять на G1GC:
-XX:+UseSerialGC заменить на -XX:+UseG1GC
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions.
В случае, если утечка памяти имеет место, то вполне реально получить результат еще хуже, поскольку мы боремся со следствием, а не первопричиной (зависит от скорости заполнения кучи и масштабов утечки). И это отнюдь не потому, что G1GC хуже Serial.
5. Можно вовсе попробовать
Авторизуйтесь для просмотра ссылок.
, которые как раз делают упор на настройку GC.
