CPU против RAM: от чего игровой сервер быстрый?

RAM определяет, сколько сервер может удержать, CPU определяет, как быстро он может думать. Почему скорость одного ядра важнее всего и когда помогают дополнительные ядра.

4 мин чтения · Обновлено 21 окт. 2026 г. · Автор: GuavaHost Team

RAM определяет, сколько ваш сервер может удержать, а CPU определяет, как быстро он может думать. Большинство серверных лагов, которые списывают на память, на самом деле проблема CPU, поэтому это руководство объясняет разницу, почему скорость одного ядра важнее числа ядер и как понять, чего именно вам не хватает.

Две разные задачи

• RAM это вместимость. Она держит мир, игроков и моды. Если её мало, сервер подвисает, пока освобождает память, либо падает.
• CPU это скорость. Он делает саму работу: двигает мобов, считает ИИ, физику, редстоун, верстаки и каждый плагин. Если его мало, сервер отстаёт, и это сразу чувствуют все как задержку и рывки.

Добавление RAM серверу, которому не хватает CPU, не даёт ничего, а быстрый CPU не спасёт сервер, у которого кончилась память. Нужно достаточно и того, и другого, но ломаются они по-разному.

Бюджет тика

Игровой сервер работает в цикле. Каждый проход цикла называется тиком, и в каждом тике сервер обновляет всё в мире. Игра ожидает определённое число тиков в секунду, и это задаёт каждому тику бюджет времени:

Если тик занимает больше своего бюджета, сервер не успевает. В Minecraft это проявляется как падение TPS (тиков в секунду) ниже 20 и рост MSPT (миллисекунд на тик) выше 50. Наше руководство как читать TPS и MSPT показывает, как это измерить.

RAM в этом бюджете не появляется нигде. Успеть завершить каждый тик вовремя это исключительно вопрос того, сколько работы есть и как быстро CPU с ней справляется.

Почему скорость одного ядра важнее всего

Большинство игровых серверов делают основную симуляцию в одном главном потоке. Поток это одна линия работы, которую может выполнять ядро CPU, а игровой мир трудно разделить на несколько, потому что каждый шаг зависит от предыдущего: моб не может шагнуть, пока сервер не знает, где оказался блок, на который он наступает.

Minecraft, Rust, ARK, Valheim, Project Zomboid и Terraria все работают так. Поэтому скорость одного ядра задаёт потолок всему серверу. CPU с 16 более медленными ядрами может вести мир Minecraft хуже, чем CPU с 8 более быстрыми, потому что для основной работы мир всегда использует только одно из них.

Скорость одного ядра складывается из двух вещей:

1. Тактовая частота, измеряемая в ГГц: сколько циклов ядро выполняет в секунду.
2. Работа за цикл, которая улучшается с каждым поколением CPU. Более новый CPU на той же частоте часто заметно быстрее старого.

Большой кэш CPU (небольшой объём очень быстрой памяти прямо на чипе) тоже помогает, потому что игровые серверы постоянно прыгают между множеством мелких кусочков данных.

Когда дополнительные ядра действительно помогают

Лишние ядра не бесполезны. Они берут на себя всё, что не относится к основному тику:

• Фоновая работа. Сохранение мира, загрузка и генерация чанков (серверное ПО вроде Paper выносит часть этого с главного потока), сжатие сетевых данных и задачи плагинов, написанные для работы в фоне.
• Сборка мусора в Java. Minecraft Java вычищает неиспользуемую память несколькими потоками, так что свободные ядра делают эти уборки короче.
• Больше одного процесса. Сервер Don't Starve Together запускает поверхность и пещеры как два отдельных процесса, а каждая карта кластера ARK это свой сервер. Каждый может занять своё ядро.
• Обновления и резервные копии. Скачивание обновления игры или сжатие резервной копии происходит рядом с игрой, а не внутри тика.

Некоторые более новые движки, включая Unreal Engine, на котором работают ARK и Palworld, распределяют больше работы по дополнительным потокам. Но даже там главный игровой поток по-прежнему задаёт темп.

Чего именно вам не хватает?

Одна деталь, которую стоит знать: карточка Usage (использование) в вашей панели управления GuavaHost (на вкладках Overview (обзор) и Console (консоль)) показывает CPU относительно вашего тарифа. Когда у тарифа есть лимит CPU, цифра это доля от всех ядер тарифа, с подписью вроде "of 2 cores", так что 100 процентов означает, что заняты все. Главный поток игры может использовать только одно ядро, поэтому на тарифе с 2 ядрами сервер, который лагает, держась около 50 процентов, вполне может упираться в предел своего главного потока, хотя запас ещё остался. Когда у тарифа нет лимита CPU, цифра это процент от одного ядра, так что сервер, который лагает около 100 процентов, это та же история. Это классический признак узкого места в главном потоке.

Как лечить лаги из-за CPU

Больше RAM здесь не поможет. Помогает то, что даёт главному потоку меньше работы на каждый тик:

1. Сначала снижайте simulation distance, затем view distance. Смотрите view distance и simulation distance.
2. Ограничьте фермы мобов и уберите выпавшие предметы и лишние сущности.
3. Сгенерируйте мир заранее, чтобы новая местность не создавалась, пока люди играют.
4. Найдите тяжёлые плагины или моды профилировщиком. В Minecraft бесплатный плагин Spark называет точно, что съедает каждый тик.
5. Поставьте ежедневный перезапуск, чтобы сбрасывать накопившиеся сущности и память.

Наш чек-лист по лагам проходит по этим шагам по порядку.

Как это устроено в GuavaHost

Каждый сервер GuavaHost работает на процессорах AMD Ryzen и Intel, выбранных за сильную производительность в одном потоке, потому что именно на неё опираются игровые серверы, и на хранилище NVMe SSD. Вы выбираете RAM, под свою игру и компанию, и можете менять её в любой момент через Manage plan (управление тарифом) в панели управления, с пропорциональным пересчётом оплаты. Если у вашего сервера есть запас памяти, но он всё равно еле справляется, это задача на настройку, и наше руководство по RAM объясняет, почему покупка памяти это не исправит.

Всё ещё не получается? Заходите в наш Discord: discord.gg/GuavaHost, и команда вам поможет.

• cpu
• ram
• performance
• single-thread
• cores
• tick rate
• lag

Всё ещё нужна помощь? Наша команда онлайн круглосуточно и ответит на ваши вопросы.

Связаться с поддержкой