Память сервера Project Zomboid: диагностика heap и лимитов Linux
Память сервера Project Zomboid: диагностика лимита

Источник Eugene от 26 октября 2026 описывает выделенный сервер Linux и указывает Stable 42.21 на дату публикации. Процесс диагностики применим и к старым серверам, но их launcher и комплектная Java могут отличаться. Ни сервер, ни конкретный образ независимо не тестировались; сохраняйте runtime выбранной сборки.
Ошибка OutOfMemoryError: Java heap space указывает на сбой выделения памяти heap; Killed или исчезновение процесса требует проверки Linux и системы управления контейнером. Повышение Xmx без определения лимита может ускорить остановку.
Сначала сохраните свидетельства
Сохраните игровой журнал и отчёт supervisor за одно время, включая строку до исключения. Отсутствующий мод, несовместимое сохранение или ошибка прав не исправляются добавлением RAM. После возможного завершения ядром сохраните остановленный мир до повторных запусков.
| Наблюдение | Что проверить по источнику |
|---|---|
| Java heap space | Фактический предел heap, нагрузку и недавние изменения модов |
| Native allocation failure / hs_err_pid | Память процесса, лимит хоста или контейнера, библиотеки и потоки |
| Killed, код 137 или сигнал 9 | Журналы OOM ядра и события памяти контейнера; один симптом не доказывает OOM |
| Ошибка резервирования при старте | Начальный и максимальный heap, адресное пространство и лимиты службы |
| Падает только клиент | Журнал и launcher клиента; изменение heap сервера может быть не связано |
Найдите действительный launcher
Клиент Steam и выделенный сервер установлены отдельно; изменение клиентского ProjectZomboid64.json не настраивает удалённый сервер. Выбор памяти в игровом Host — другой путь запуска. Если Linux start-server.sh запускает нативный ProjectZomboid64, автор указывает vmArgs в соседнем серверном ProjectZomboid64.json; если wrapper запускает Java напрямую, определяющими могут быть его аргументы. Проверьте реальный скрипт и вывод запуска.
Панель или entrypoint контейнера могут перезаписывать JSON. Автор приводит конкретный образ indifferentbroccoli с MEMORY_XMX_GB и необязательным MEMORY_XMS_GB: эти переменные нельзя считать универсальными для других образов. Windows StartServer64.bat не переносится в Linux. Сохраните исходную конфигурацию и не меняйте classpath, пути нативных библиотек и комплектный runtime.
Heap, RSS и лимит контейнера
Xmx задаёт потолок heap, а Xms — начальный heap; нативные выделения, стеки потоков и другие области JVM требуют дополнительной памяти. RSS отражает резидентные страницы; большой VSZ сам по себе не доказывает исчерпание физической RAM. Автор предлагает следующие команды для проверенного PID игрового процесса, не PID оболочки; команды приведены для чтения и не выполнялись.
PZ_PID=12345
ps -p "$PZ_PID" -o pid,rss,vsz,etime,comm
readlink -f "/proc/$PZ_PID/cwd"
cat "/proc/$PZ_PID/cgroup"
free -h
journalctl -k --since '30 minutes ago' --no-pager
RSS и VSZ в этом выводе ps указаны в KiB. Для журнала ядра могут понадобиться права; сопоставляйте OOM-kill с PID и временем события. В cgroup v2 определите настоящую группу игрового процесса и проверьте memory.current, memory.max и memory.events, в том числе oom_kill до и после события и лимиты предков. Не предполагайте, что /sys/fs/cgroup произвольной оболочки относится к игре: пространство имён контейнера может отличаться. Лимит контейнера может исчерпаться при свободной RAM хоста.

Схема источника предлагает определить характер сбоя и действующие пределы, изменить один параметр и повторить сопоставимую нагрузку.
Изменение и проверка
Только при подтверждённом исчерпании heap и достаточном запасе всего процесса автор предлагает увеличить потолок. Его пример — -Xmx6g при исключительно выделенном лимите 12 GiB — это иллюстрация эксперимента, не требование игры и не универсальная рекомендация на число игроков. Измерьте потребление при реальной нагрузке. При давлении native или cgroup увеличение heap может сократить оставшийся запас; рассматривайте меньший heap, меньше соседних процессов или больший лимит после измерений.
Не приравнивайте Xms ко всей RAM хоста; убедитесь, что начальный heap не выше нового максимума. После сохранения и остановки сервера автор предлагает изменить существующую строку Xmx в действующем vmArgs JSON или настройку wrapper, если он задаёт значение. Сохраняйте структуру и только один предполагаемый максимум; суффикс важен: -Xmx6 не означает 6 GiB.
"-Xmx6g"
Запустите сервер обычным способом и изучите новый вывод: выбранную конфигурацию и фактический heap. Нативный launcher может читать JSON без отображения аргументов в /proc/PID/cmdline, поэтому их отсутствие там не доказывает игнорирование. Если диагностики нет, используйте совместимый инструмент JVM или документированную диагностику wrapper; одного редактирования файла недостаточно.
Повторите сопоставимую нагрузку игроков, модов и областей, наблюдая heap, RSS, cgroup и ошибки. Сохраните мир, остановите и снова запустите сервер. Если память продолжает расти при похожей нагрузке, исследуйте изменения сборки или модов на отдельной копии, не удаляя контент из единственного рабочего сохранения. После обновлений снова проверяйте launcher: валидация пакета или entrypoint могут заменить ручную правку.
Источники
История версий The Indie Stone
Поддержка Linux: конфигурация
Форум: память сервера Build 42
Настройки контейнерного образа
Java: параметры heap
Java: диагностика памяти
Linux: cgroup v2
Резервная копия сервера