Wayfarer
Пользователь
- Сообщения
- 203
- Решения
- 2
К сути, есть алгоритм, ищущий путь к игроку, который должен учитывать расстояния в 48+ блоков радиусом и пока путь ищется, создаются огромная куча короткоживущих объектов (Node), который съедает фибоначчиевая куча для рассчёта эффективного маршрута (а для маленьких расстояний наикратчайшего). Из-за таких приколов и частых вызовов алгоритма (пусть надо перерассчитывать часто из-за динамичного мира, где всё время что взрывается, ставится, ломается (из блоков)) часто работает сборщик мусора, который выносит молодое поколение, по таймингам спарк каждые 6 секунд вызывается при небольшой кучке мобов. Из проведённых оптимизаций: не рассчитывается длинный маршрут для множества мобов в одной зоне (16х16х16), один ищет на 48+ блоков, остальным радиус поиска урезается. Вынес как можно больше проверок до того, как будет создан новый объект, что немного помогло. Собственно, а если мобов будет 100+ на сервере? А если 300+? Я просто знаю, если цифра в таймингах жёлтенькая, значит нехорошо, зелёненькая - хорошо. Это я вижу как бутылочное горлышко моего плагина, как можно это всё оптимизировать? И настолько критично ли?
Для запуска сервера у меня стандартный конфиг с сайта пейпер
Для запуска сервера у меня стандартный конфиг с сайта пейпер
Код:
"C:\Program Files\Java\jdk-22.0.1\bin\java.exe" -jar
-Xms6192M -Xmx6192M -XX:+UseG1GC -XX:+ParallelRefProcEnabled
-XX:MaxGCPauseMillis=200 -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
-Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true paper.jar
pause
