Производительность сервера Project Zomboid в образе Faudil Docker

Документация Faudil для своего Docker-образа Build 42 рассматривает нагрузку CPU и RAM, настройки JVM, мира и контейнера. Значения и эффект — оценки автора, не результаты наших тестов. Примеры относятся к конкретному образу и закреплённой версии документации; команды не выполнялись.

Приоритеты и память JVM

По описанию образа, entrypoint при каждом старте меняет ProjectZomboid64.json, передавая MAX_RAM, MIN_RAM, GC_CONFIG и JVM_EXTRA_ARGS; исходные параметры игры иначе могли бы их перекрыть. Автор предлагает одинаковые MIN_RAM и MAX_RAM, а расходы JVM сверх Xmx оценивает в 20–30%; реальные значения надо измерять.

Автор рекомендует ZGC; при высокой загрузке CPU предлагает исследовать G1 с GC_CONFIG=G1 и JVM_EXTRA_ARGS="-XX:MaxGCPauseMillis=100". Это требует проверки на своей нагрузке; таблица не гарантирует отсутствие пауз или OOM.

Режимы песочницы

SANDBOX_* по источнику переопределяют режим. Автор сохраняет ZombiesCountBeforeDelete=300 и RollsMultiplier=1.0, предупреждая о возможной нагрузке при повышении; также утверждает, что правила очистки относятся к новым предметам, а старый мусор сохраняется до перезагрузки чанка. Все эти механики требуют проверки версии. Ссылки на CONFIGURATION.md и .env.example в закреплённом коммите не были получены и остаются неподтверждёнными.

Ресурсы контейнера

Пример автора для хоста с 16 ГБ и четырьмя физическими ядрами использует образ ghcr.io/faudil/project-zomboid-server-docker:latest, mem_limit 12g, cpuset 0-3, cpu_shares 1024, nofile 65535, SANDBOX_MODE=max и MIN_RAM/MAX_RAM=8192m. Томам ./data, ./server-files и ./backups соответствуют /home/steam/Zomboid, /home/steam/pzserver и /home/steam/Zomboid/backups. Это пример, а не универсальная конфигурация; latest не закрепляет версию образа.

services: zomboid: image: ghcr.io/faudil/project-zomboid-server-docker:latest restart: unless-stopped # 8g heap + ~25% JVM overhead, plus headroom for the OS cache mem_limit: 12g # Pin to 4 physical cores; on hosts with hyperthreading avoid # siblings (e.g. cores 0-3 instead of 0-7) cpuset: "0-3" # Tune the CPU share if other containers share the box cpu_shares: 1024 ulimits: nofile: soft: 65535 hard: 65535 environment: SANDBOX_MODE: max MAX_RAM: 8192m MIN_RAM: 8192m volumes: - ./data:/home/steam/Zomboid - ./server-files:/home/steam/pzserver - ./backups:/home/steam/Zomboid/backups

Автор советует оставить запас памяти над Xmx, учитывать физические ядра и соседние потоки CPU, хранить data на SSD/NVMe и отмечает возможные задержки NFS или дисков. PAUSE_ON_EMPTY=true описан как значение по умолчанию для снижения нагрузки пустого сервера.

Параметры хоста и сеть

Автор предлагает исследовать vm.swappiness=1, transparent huge pages в режиме madvise, governor performance, vm.max_map_count=262144, сетевые буферы net.core.rmem_max и net.core.wmem_max по 26214400, а также noatime для тома; для больших миров упоминает необязательный vm.overcommit_memory=1. Заявленные эффекты не проверялись и не являются общими рекомендациями для любого хоста.

# Reduce swap pressure; the game is latency-sensitive (swap-in = stutters) sudo sysctl vm.swappiness=1 # Transparent huge pages break ZGC's low-pause guarantees (latency spikes). # "madvise" lets the JVM opt in explicitly, which is what it wants. echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled # Keep the CPU at full frequency instead of power-saving scaling lag sudo cpupower frequency-set -g performance # or set the scaling_governor manually # ZGC creates many virtual memory mappings on large (>8G) heaps; the default # max_map_count (65530) can be too low and cause "mmap failed" at startup sudo sysctl vm.max_map_count=262144 # UDP receive/send buffers: helps when 16+ players are connected and avoids # dropped packets under load sudo sysctl net.core.rmem_max=26214400 sudo sysctl net.core.wmem_max=26214400 # Mount the data volume without atime updates: the game reads save chunks # constantly, and atime writes on every read are pure overhead # (add "noatime" to the fstab entry or mount options)

Ротация Docker json-file в примере ограничена max-size=10m и max-file=3; для docker run автор приводит аналогичные log-opt. Режим network_mode: host обходит bridge/NAT, но использует сетевой стек хоста и убирает сетевую изоляцию контейнера; сервер может слушать все интерфейсы. Применимость и влияние на задержку требуют отдельной оценки.

logging: driver: "json-file" options: max-size: "10m" max-file: "3"

services: zomboid: network_mode: host

Резервные копии, перезапуск и мониторинг

Источник описывает AUTOSAVE_INTERVAL=15 минут и резервные архивы BACKUP_ENABLED=true с BACKUP_INTERVAL=360 минут; для больших миров предлагает сдвигать копирование на непиковое время. Хотя источник допускает отключение архивов с опорой на снимки хоста, автосохранение не является резервной копией: сохраняйте независимые восстанавливаемые копии и проверяйте восстановление.

UPDATE_ON_START=false, по автору, пропускает проверку DepotDownloader и ускоряет перезапуск, но не получает обновления автоматически; true описан как стандарт. Healthcheck имеет start-period=600s для первой загрузки; последующие запуски автор оценивает в 1–2 минуты. Для наблюдения он предлагает docker stats и RSS относительно mem_limit, а также команду TPS в админ-консоли; диапазон 30–60 TPS и причины длительных падений — эвристики автора, требующие проверки.