Залізо для ігрового сервера: частота важливіша за ядра
Ігровий сервер рахує світ в одному потоці: увесь тик — фізика, ШІ, події — виконується на одному ядрі. Тому вирішує частота цього ядра і стабільність її утримання, а не загальна кількість ядер. Ядра потрібні там, де ви піднімаєте кілька інстансів поруч: кожен отримає своє. Пам'ять беруть за кількістю інстансів, диск — NVMe під завантаження карт і збереження.
- Один світ = одне ядро. Вісім ядер не пришвидшать один тик, але дозволять тримати вісім світів.
- Бюджет тика за 20 tps — 50 мс, за 64 tps — близько 15 мс. Вихід за бюджет гравці бачать як ривки.
- Пам'ять: по 4–8 GB на світ у Minecraft Java, по 1–2 GB на інстанс Source, по 8–16 GB на великий світ Rust.
- Ігровий трафік — це багато дрібних UDP-пакетів, а не гігабіти. Канал упирається в pps, а не в ширину.
- Governor у режимі powersave дає плавучу частоту й нестабільний тик; ставте performance.
Чому частота, а не кількість ядер
Цикл симуляції у більшості рушіїв послідовний: сервер обраховує стан світу, розсилає знімки і засинає до наступного тика. Розпаралелити цей цикл не можна, бо кожен крок залежить від результату попереднього. Ядро з вищою частотою проходить той самий цикл за менший час — це прямий виграш, видимий на графіку часу тика.
Багатоядерність працює інакше: вона дає ізоляцію. Три світи Minecraft на трьох ядрах не заважають одне одному, а один світ на дванадцяти ядрах вантажитиме одне ядро і простоюватиме на решті. Загальна логіка вибору процесора під задачу розібрана у статті про вибір процесора для сервера.
Звідси практичний висновок: на одному важкому світі з сотнею гравців тариф з E3-1270v6 може відпрацювати не гірше за двопроцесорну машину, а на десяти невеликих світах виграє E5-2680v4 з більшою кількістю потоків.
Скільки пам'яті й диска потрібно
| Профіль | RAM на інстанс | Що ще критично | Відповідний тариф |
|---|---|---|---|
| Minecraft Java, 20–40 гравців, модпак | 6–8 GB | Частота ядра, NVMe під генерацію чанків | Start DE / Start FR |
| Source-ігри, 3–5 інстансів | 1–2 GB | Стабільний tickrate, низький джитер | Start DE / Start US |
| Rust, середній світ | 10–16 GB | Пам'ять і швидкість завантаження світу | Pro DE / Pro FR |
| 10 і більше світів разом | 32–64 GB сумарно | Кількість потоків, RAID10 під збереження | Enterprise US |
Старт світу читає з диска сотні мегабайтів, а автозбереження пише їх назад під навантаженням: на SATA SSD це помітна просадка тика, на NVMe вона зникає. Тарифи Pro та Enterprise ідуть з NVMe у RAID1 і RAID10, конфігурації перелічені на сторінці виділених серверів.
Канал, затримка й локація
Ігровий сервер надсилає кожному гравцеві знімок щотика. Ширина каналу при цьому витрачається скромно, а от пакетів на секунду виходить багато, і саме їх обробляє мережевий стек. Unmetered-канал на 100 Мбіт/с у Німеччині спокійно тримає десятки ігрових слотів, але ліміт трафіку варто перевірити, якщо ви ще й роздаєте модпаки: про це у статті про канал сервера та ліміти трафіку.
Затримка до гравців важливіша за решту заліза. Обирайте майданчик за географією аудиторії та перевіряйте його вимірами — методика описана у статті про вибір локації сервера.
Налаштування Linux під стабільний тик
Три речі дають більше, ніж будь-які «оптимізації» конфігу гри: фіксована частота, збільшені мережеві буфери та пріоритет процесу.
# Debian/Ubuntu: фіксуємо частоту на максимум
apt-get install -y linux-cpupower
cpupower frequency-set -g performance
# RHEL/AlmaLinux/Rocky
dnf install -y kernel-tools tuned
tuned-adm profile latency-performance
# перевіряємо, що частота справді тримається
grep MHz /proc/cpuinfo | head -4
cpupower frequency-info | grep -E 'governor|current'# мережеві буфери під багато дрібних UDP-пакетів
cat << 'EOF' > /etc/sysctl.d/90-game.conf
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 5000
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384
EOF
sysctl --system 2>&1 | grep -E 'rmem_max|backlog'
# пріоритет процесу світу і його диску
systemctl set-property game@world1.service CPUWeight=900 IOWeight=900Після змін дивіться не на середній час тика, а на максимум за хвилину: ривки живуть саме в піках. Якщо піки збігаються з автозбереженням, рознесіть збереження різних світів у часі.
Ігрові порти живуть на UDP, і фільтрація L7 їх не закриває: проти флуду на ігровий порт працює саме L3/L4-захист на рівні аплінка. На майданчиках у Німеччині та США він увімкнений на всіх тарифах, у Франції працює Anti-DDoS Arbor; подробиці — у статті про DDoS-захист виділеного сервера. Друга типова помилка — лишити governor у powersave і потім шукати причину ривків у конфігу гри. Перевіряйте так: запустіть навантаження, зніміть grep MHz /proc/cpuinfo кілька разів поспіль і переконайтеся, що частота не провалюється між замірами.
Коротко
- Один світ рахується одним ядром: частота дає прямий виграш у часі тика, кількість ядер — лише в кількості світів.
- Пам'ять планують за інстансами: 6–8 GB на модпак Minecraft, 1–2 GB на інстанс Source, 10–16 GB на світ Rust.
- NVMe прибирає просадки тика на автозбереженні та генерації карти, SATA SSD їх лишає.
- Канал витрачається на пакети, а не на гігабіти; критичніша за ширину — затримка до аудиторії.
- Governor performance, збільшені UDP-буфери та пріоритет процесу дають більше, ніж правки конфігу гри.