Сообщение OutOfMemoryError: Java heap space и исчезновение сервера со строкой Killed требуют разных проверок. Первое указывает на нехватку места в Java heap; для второго нужны сведения Linux или супервизора контейнера. Увеличение -Xmx без понимания причины может ускорить следующее аварийное завершение.
Речь о выделенном Linux-сервере. На 26 октября 2026 года текущая Stable-сборка — 42.21. Порядок диагностики подходит и для сохранённых старых серверов, но их загрузчики и комплектная Java могут отличаться. Оставьте среду выполнения из выбранной сборки: установка другой системной Java не является настройкой памяти.
Прочитайте ошибку до изменения лимита#
Сохраните журнал игры и отчёт супервизора за время одного сбоя. Нужен полный текст ошибки, а не только сообщение об отключении клиента:
| Наблюдение | Что проверять дальше |
|---|---|
OutOfMemoryError: Java heap space | Фактический предел heap, недавнюю нагрузку и изменения модов |
Ошибка native allocation или файл hs_err_pid | Память процесса, доступный бюджет машины/контейнера, нативные библиотеки и потоки |
Killed, код 137 или сигнал 9 | Сообщения OOM ядра и события памяти контейнера; сами эти признаки ещё не доказывают OOM |
| Невозможно зарезервировать память при запуске | Начальный и максимальный heap, лимиты адресного пространства или службы |
| Падает только игра одного участника | Его клиентский журнал и загрузчик; heap сервера может быть ни при чём |
Посмотрите и строки перед исключением. Отсутствующий мод, несовместимое сохранение или ошибка доступа не исправляются дополнительной RAM. Если ядро завершило процесс, перед повторными попытками запуска сохраните остановленный мир целиком по инструкции резервного копирования.
Найдите загрузчик именно выделенного сервера#
Клиент игры в Steam и инструмент Dedicated Server устанавливаются отдельно. Изменение клиентского ProjectZomboid64.json не настраивает удалённый сервер. Ползунок памяти в игровом меню Host относится к ещё одному способу запуска.
Если Linux-пакет запускает через start-server.sh нативный загрузчик ProjectZomboid64, параметры heap обычно находятся в vmArgs соседнего серверного ProjectZomboid64.json. Сверьте действующий скрипт и начальные строки вывода: оболочка, напрямую запускающая Java, может брать параметры из собственного списка аргументов. Windows-пакет может вызывать комплектную Java из StartServer64.bat; переносить этот файл в Linux не нужно.
Панель или entrypoint контейнера способны переписывать JSON при каждом старте. Например, поддерживаемый образ indifferentbroccoli задаёт значения через MEMORY_XMX_GB и необязательный MEMORY_XMS_GB. Это переменные конкретного образа. Для другой установки нужны её документированные настройки, а не похожие названия переменных.
Сохраните исходную конфигурацию загрузчика. Убедитесь, что открыли каталог выделенного сервера, и оставьте его classpath, пути нативных библиотек и комплектную Java без изменений.
Разделите heap, память процесса и доступный бюджет#
-Xmx ограничивает heap, а не весь серверный процесс. -Xms задаёт начальный размер heap. Нативным выделениям, стекам потоков и другим областям JVM нужно место снаружи. RSS показывает резидентные страницы процесса; большой VSZ включает виртуальное адресное пространство и сам по себе не означает исчерпанную физическую RAM.
На Linux-хосте замените 12345 проверенным 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 определите настоящую cgroup игры по её процессу и проверьте memory.current, memory.max и memory.events в подключённой иерархии. Сравните счётчик oom_kill до и после события. Учитывайте лимиты родительских групп. Контейнер способен исчерпать свою квоту, даже когда на хосте ещё есть свободная RAM. Путь /sys/fs/cgroup внутри произвольной оболочки не обязательно относится к игре, особенно при разных пространствах имён контейнера.
Меняйте одно значение и оставляйте измеримый запас#
При подтверждённой нехватке heap увеличивайте максимум только в пределах бюджета, который вместит выросший процесс. Условный пример для первого замера: при отдельном бюджете 12 GiB можно проверить -Xmx6g. Это не системное требование игры и не обещание определённого числа игроков. Следующее значение выбирайте по фактической памяти занятой сессии.
При нехватке нативной памяти или давлении cgroup более крупный heap может уменьшить оставшийся запас. После измерений рассмотрите меньший heap, сокращение конкурирующей нагрузки или увеличение квоты. Не выставляйте -Xms равным всей RAM машины. Проверьте, что существующий начальный размер не превышает новый максимум.
Сохраните мир и остановите сервер. В конфигурации, которую действительно использует загрузчик, измените существующий элемент -Xmx массива vmArgs. Для приведённого примера это одна JSON-строка:
"-Xmx6g"
Сохраните остальные части файла и убедитесь, что не добавили конкурирующий максимальный лимит. Указывайте суффикс размера: -Xmx6 не означает шесть гигабайт. Если значение задаёт оболочка, исправляйте её исходную настройку.
Проверьте новый старт и привычную нагрузку#
Запустите сервер обычным способом и найдите в свежем выводе выбранный файл конфигурации и значение heap среди vmArg. Нативный загрузчик может читать JSON без появления этих параметров в /proc/PID/cmdline: их отсутствие там не доказывает, что настройка проигнорирована. Если загрузчик не выводит параметры, используйте доступный совместимый инструмент JVM либо диагностику самой оболочки. Одного сохранения файла недостаточно.
Подключитесь, посетите места, где происходил сбой, и воспроизведите соответствующую нагрузку игроков и модов. Записывайте лимит heap, RSS, память cgroup и ошибки во времени. Затем ещё раз сохраните сервер, остановите и запустите его. Если расход продолжает расти при сопоставимой нагрузке, исследуйте изменение сборки или мода на отдельной копии. Не удаляйте контентные моды из единственного рабочего сохранения ради эксперимента.
При управлении собственными машинами через Nexardo фиксируйте в изменениях и бюджет инфраструктуры, и фактический heap игры. После обновления снова проверьте загрузчик: проверка пакета или entrypoint способны заменить ручную правку.
