До серии перезапусков Palworld сохраните время завершения и свидетельства операционной системы. Код 137 или одинокая строка Killed говорят о резком завершении, но не объясняют причину. Нужно связать игровой процесс с событием нехватки памяти и выяснить, где проходит достигнутый предел: на хосте, у службы, контейнера или виртуальной машины.
Разбираем выделенные Linux-серверы, включая Docker и cgroup v2. В примерах используется palworld.service из инструкции по установке; замените имя на фактическую службу или контейнер. Источники проверены 18 октября 2026 года, документация Pocketpair показывает 1.0.4. Универсальное число гигабайт не заменяет измерений вашего мира и нагрузки.
Сохраните сведения за окно сбоя#
Запишите момент отключения игроков, последнее успешное сохранение и автоматический перезапуск, если он был. До ротации журналов прочитайте события службы и ядра за нужное время:
date --iso-8601=seconds
sudo systemctl show palworld -p Result -p ExecMainCode -p ExecMainStatus -p NRestarts -p MainPID
sudo journalctl -u palworld --since '1 hour ago' --no-pager
sudo journalctl -k --since '1 hour ago' --no-pager
journalctl -k выбирает текущую загрузку ОС. Если после сбоя хост перезагружался, найдите нужную загрузку через sudo journalctl --list-boots; для непосредственно предыдущей используйте sudo journalctl -k -b -1. Сверяйте время именно той загрузки с ошибкой игры: отсутствие сохранённого журнала не опровергает OOM.
Подберите окно под фактический инцидент. Найдите событие OOM с убитым процессом и его cgroup, затем сопоставьте с завершением игры. Сравнивайте время и загрузку ОС: вчерашняя запись ядра не объясняет сегодняшнее независимое падение. Если доступ к журналу ядра ограничен или события хранятся иначе, запросите запись у администратора хоста. Пустой поиск не опровергает OOM.
Отказ выделения памяти внутри игры тоже способен дать ошибку out-of-memory без убийства ядром. Такой crash log сохраняется отдельно. При этом SIGKILL может прийти от администратора, тайм-аута остановки supervisor или другой политики. Нельзя автоматически называть любое резкое завершение утечкой памяти.
Сравните память хоста и предел службы#
free -h
sudo systemctl show palworld -p MemoryCurrent -p MemoryPeak -p MemoryHigh -p MemoryMax -p ControlGroup
free описывает тот хост, где выполнена команда. Он не показывает разрешённый объём ограниченной службы. Сам хост может оказаться VM с меньшим выделенным объёмом, чем память физического компьютера. Проверьте также родительские slices или границу контейнера: свободная настройка unit не отменяет более строгий предел предка.
В системе с единой иерархией cgroup v2, пока соответствующая cgroup службы существует:
(
set -e
palworld_cgroup=$(systemctl show palworld -p ControlGroup --value)
test -n "$palworld_cgroup"
test "$palworld_cgroup" != /
sudo test -f "/sys/fs/cgroup${palworld_cgroup}/memory.events"
sudo cat "/sys/fs/cgroup${palworld_cgroup}/memory.current"
sudo cat "/sys/fs/cgroup${palworld_cgroup}/memory.max"
sudo cat "/sys/fs/cgroup${palworld_cgroup}/memory.events"
)
Назначение файлов определяет документация ядра. Конечное значение memory.max — ограничение, а не установленная память хоста. Рост oom_kill означает убийство по OOM среди процессов этой cgroup. Сохраните значения до и после и сопоставьте со временем сбоя: накопленный счётчик сам по себе не устанавливает причину одного инцидента. Пересоздание cgroup способно обнулить его. Если служба завершилась и cgroup исчезла, используйте сохранённые журналы и данные supervisor.
Справочник systemd также различает торможение на MemoryHigh и жёсткий предел MemoryMax. Давление памяти и замедление сохранений возможны до убийства процесса. Бесконтрольное увеличение второго значения может перенести проблему на соседние службы или весь хост.
В Docker различайте игру и обёртку#
Для контейнера, который действительно называется palworld:
docker inspect --format '{{json .State}}' palworld
docker inspect --format 'Memory={{.HostConfig.Memory}} MemorySwap={{.HostConfig.MemorySwap}}' palworld
docker stats --no-stream palworld
Используйте принятый у вас способ административного доступа к Docker. Новый пересозданный контейнер не сохраняет состояние прежнего: запишите исходный идентификатор и время сбоя. .State.OOMKilled полезен при завершении самого контейнера по OOM, но не покрывает все случаи убийства дочерней игры при живой обёртке. Дополнительно нужны свидетельства ядра хоста и подходящих cgroup-счётчиков.
Документация Docker об ограничениях памяти объясняет, почему свободная RAM в другой части машины не отменяет потолок контейнера. Подписывайте измерения хоста, cgroup и процесса отдельно: RSS процесса и общий расход контейнера — разные величины.
Сравнивайте одинаковые прогоны#
Зафиксируйте точную сборку сервера, native Linux или Wine, моды, возраст мира, игроков, базы, Pals и сохранения. Измеряйте память с одинаковым интервалом после запуска, без игроков, при сопоставимой активной нагрузке и во время сохранения. Сохраняйте время измерений, а не только максимум графика.
В сообщении администратора за июль 2026 года описаны рост памяти и убийства ядром в связке Wine с контейнером даже после увеличения лимита. Это одна заявленная среда, а не доказательство той же причины у любого native-сервера. Её числа не определяют необходимый объём вашей установки.
Меняйте по одному фактору. Сравнение модов, runtime или настроек мира проводите на независимой копии: удалять контент и сохранять единственный рабочий мир поверх исходного нельзя. Рост графика при новой нагрузке — симптом для наблюдения. Для вывода об утечке нужно больше, чем большое число или уменьшение расхода после перезапуска.
Выберите меру и проверьте восстановление#
Требования Pocketpair указывают 16 GB и рекомендацию свыше 32 GB, отдельно отмечая риск OOM при 8 GB. Это ориентиры, а не гарантия вместимости развитого мира. Оставьте запас ОС, соседним нагрузкам и пикам сохранения; выбирайте ограничения по измерениям.
Возможные меры — уменьшить одновременную нагрузку, выделить реально свободную память, разнести конкурирующие службы или проверить сборку с подходящим исправлением. Изучите аргументы: актуальная рекомендация Pocketpair для 1.0 уже не считает старые performance-флаги автоматическим улучшением. Перезапуск по расписанию может временно облегчить эксплуатацию, но не доказывает устранение причины. Сохраняйте и завершайте игру мягко, вместо регулярного SIGKILL.
После принудительного завершения сохраните полное текущее дерево данных до экспериментов. Запустите нужный мир, изучите ошибки загрузки и записи, войдите, проверьте важный прогресс, выполните мягкое сохранение и перезапуск. Подтверждение результата требует сопоставимой нагрузки без нового связанного OOM и целого сохранения. Честно запишите длительность наблюдения: короткий простой не подтверждает устойчивость на прежнем пике.
