Миф: больше ядер — быстрее сайт

MAATRIX

Открываете страницу тарифов, сравниваете VPS — и первое, на что падает взгляд, это число ядер. 4 vCPU дешевле, 8 vCPU дороже, значит 8 — быстрее, логично же. Только сайт после переезда на «более мощный» тариф грузится ровно с той же скоростью, что и раньше. Разбираемся, почему число ядер — это не то же самое, что скорость отклика, и где эта путаница реально стоит денег.

Как звучит миф и откуда он берётся

Формулировка, с которой сталкивается почти каждый, кто выбирает тариф: «чем больше ядер, тем быстрее будет работать сайт». Она выглядит настолько очевидной, что её редко подвергают сомнению — ведь с оперативной памятью и диском примерно так и работает: больше RAM — меньше свопа, быстрее NVMe — быстрее запись. Кажется естественным распространить эту логику и на процессор.

Панели управления хостингом только подливают масла в огонь: в списке тарифов ядра идут первой строкой, крупным шрифтом, ещё до частоты и уж тем более до архитектории. Маркетинг тоже играет на этом — «16 ядер» звучит солиднее, чем «4 ядра на 4.5 ГГц», хотя во втором случае для большинства сайтов отклик может быть быстрее.

Рациональное зерно в мифе есть, и оно немаленькое. Проблема не в том, что ядра не важны — а в том, что важны они для другой задачи, чем та, которую читатель обычно имеет в виду.

Где миф правдив: параллельная нагрузка

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

Это хорошо видно на типичной схеме веб-сервера:

Nginx (принимает соединения)
   │
   ├── PHP-FPM worker 1  → ядро 1
   ├── PHP-FPM worker 2  → ядро 2
   ├── PHP-FPM worker 3  → ядро 3
   └── PHP-FPM worker 4  → ядро 4

Здесь каждый воркер — отдельный процесс, и если ядер четыре, ОС действительно может исполнять их буквально одновременно, а не по очереди с переключением контекста. Для нагруженного интернет-магазина в чёрную пятницу или новостного сайта с наплывом трафика это разница между «сайт держится» и «502 Bad Gateway».

То же самое с базами данных: PostgreSQL и MySQL умеют обрабатывать несколько подключений параллельно, и на сервере с большим числом одновременных клиентов дополнительные ядра снимают часть очереди. Если у вас именно такой профиль нагрузки — много параллельных запросов от разных людей — ядра работают ровно так, как обещает миф. Разбор того, как процессор влияет конкретно на СУБД, — в статье про выбор процессора для баз данных.

Где миф ломается: скорость ОДНОГО запроса

А теперь ключевой момент, который миф упускает: скорость обработки одного конкретного запроса — того, который сейчас ждёт именно ваш посетитель, — определяется не количеством ядер, а тем, насколько быстро одно ядро выполняет свою цепочку инструкций.

Запрос «отдай главную страницу» в типичном веб-приложении — это в основном последовательная цепочка: принять HTTP-запрос → распарсить → сходить в базу → собрать шаблон → отдать HTML. Эта цепочка почти никогда не размазывается по нескольким ядрам одновременно — она исполняется одним потоком от начала до конца. Даже если рядом простаивают ещё 15 ядер, они не ускорят именно эту цепочку: она физически не может исполняться параллельно сама с собой, потому что каждый шаг зависит от результата предыдущего.

Скорость такой цепочки определяется однопоточной производительностью ядра — это комбинация тактовой частоты, архитектуры (IPC — количество инструкций за такт) и объёма кэша. Вот почему на бумаге «слабый» процессор с 4 ядрами на высокой частоте и современной архитектурой может отдавать одну страницу быстрее, чем «мощный» процессор с 16 ядрами, но низкой частотой на ядро — типичная ситуация для серверных CPU, где производитель жертвует частотой ради количества ядер в одном корпусе.

Грубая иллюстрация (условные величины для наглядности, не измеренный бенчмарк):

Если у вас сайт с умеренной посещаемостью — блог, лендинг, корпоративный сайт, — реальный пользовательский опыт («быстро открылась страница») формируется в первую очередь однопоточной производительностью, а не числом ядер. Похожая логика разбирается и в статье про NUMA и ситуации, когда два CPU работают медленнее одного — там тоже интуиция «больше железа = быстрее» подводит из-за архитектурных нюансов.

Где миф ломается: узкое место часто вообще не в CPU

Второй, ещё более частый случай — это когда сайт тормозит совсем не из-за процессора, и добавление ядер не решает проблему в принципе, потому что проблема лежит в другом слое.

Типичные немедленные (не CPU) узкие места:

• Диск. Медленный I/O при записи сессий, логов, временных файлов или при чтении с диска, если данные не помещаются в кэш. Ядра тут ни при чём — процесс просто ждёт ответа от накопителя. Подробнее — в материале о важности скорости диска для баз данных.
• Сеть. Задержка до внешнего API, платёжного шлюза, стороннего сервиса геолокации — сайт ждёт ответ по сети, и хоть 64 ядра поставь, они будут простаивать в ожидании TCP-хендшейка и ответа.
• Неоптимизированные запросы к базе данных. Запрос без индекса на таблице в миллион строк будет выполняться секунды независимо от того, сколько ядер у сервера — это работа планировщика запросов и индексов, а не параллельных вычислений. Разбор конкретных причин — в статье про медленные запросы MySQL.
• N+1 запросы. Классическая проблема ORM-фреймворков: вместо одного запроса «дай мне посты со всеми авторами» код делает один запрос на список постов, а затем ещё по одному запросу на автора каждого поста. 50 постов — 51 запрос вместо одного-двух. Каждый из этих запросов сам по себе быстрый, но их последовательное выполнение и сетевые задержки между приложением и базой суммируются в заметное время ответа. Проблема архитектурная, и лишние ядра её не решают — нужно чинить код (eager loading, JOIN вместо цикла запросов).

Диагностика в такой ситуации начинается не с htop и загрузки CPU, а с профилирования: сколько времени запрос проводит в ожидании диска (iowait), сколько — в ожидании ответа от базы, сколько — реально выполняя вычисления на CPU. Если iowait или время ожидания базы составляет основную долю, а загрузка CPU при этом невысокая — история как раз про то, что дополнительные ядра тут бессильны.

Где миф ломается: рантайм не использует ядра сам по себе

Третий нюанс — чисто технический, но именно он чаще всего оставляет людей с ощущением «купил больше ядер, а толку ноль». Многие языки и рантаймы не распределяют нагрузку по ядрам автоматически, без явной настройки.

Классический пример — Node.js. Стандартный процесс Node.js исполняет ваш JavaScript-код в одном потоке (event loop), и без явного запуска кластера (модуль cluster) или отдельного процесс-менеджера дополнительные ядра сервера для него попросту не существуют — весь код крутится на одном ядре, остальные простаивают:

// Без кластеризации — использует одно ядро, сколько бы их ни было на сервере
const http = require('http');
http.createServer((req, res) => {
  res.end('hello');
}).listen(3000);

// С кластером — реально задействует несколько ядер
const cluster = require('cluster');
const os = require('os');

if (cluster.isPrimary) {
  const cpus = os.cpus().length;
  for (let i = 0; i < cpus; i++) cluster.fork();
} else {
  require('./app.js');
}

Похожая история с PHP: без правильно настроенного пула PHP-FPM (директивы pm.max_children, pm.start_servers в /etc/php/8.3/fpm/pool.d/www.conf) даже сервер с 32 ядрами может обрабатывать запросы через горстку воркеров, а остальные ядра будут простаивать. Это тот же принцип, что разбирается в статье про Ollama, которая не использует все ядра CPU — там нейросетевой инференс, но логика идентична: ядро существует физически, но софт должен явно знать, что его нужно занять.

Проверить, сколько воркеров реально запущено и как они разложены по ядрам, можно так:

# Сколько процессов PHP-FPM активно
ps aux | grep php-fpm | wc -l

# Загрузка по каждому ядру отдельно (не средняя!)
mpstat -P ALL 1 5

Если mpstat показывает, что половина ядер простаивает под нагрузкой, а другая половина забита на 100% — это почти всегда вопрос настройки числа воркеров, а не недостатка ядер.

Пример: когда вера в миф обошлась дорого

Реальная и очень распространённая ситуация. Небольшой интернет-магазин на связке PHP + MySQL рос по трафику, и главная страница каталога стала открываться за 2-3 секунды вместо привычных 400-500 мс. Владелец, ориентируясь именно на число ядер в панели тарифов, переехал с сервера на 4 ядрах (частота около 3.5 ГГц) на сервер с 16 ядрами, но на процессоре с более низкой частотой на ядро, ориентированном именно на плотность параллельных задач, а не на однопоточную скорость. Логика была ровно такая, как в мифе: «больше ядер — сервер мощнее — страница откроется быстрее».

После переезда время отклика главной страницы не изменилось вообще — те же 2-3 секунды. Причина вскрылась при профилировании: страница каталога делала для каждого товара отдельный запрос на получение остатков на складе — классический N+1, 80 товаров на странице означали 81 обращение к MySQL. Каждое обращение по отдельности выполнялось быстро, но последовательно, одно за другим, в рамках одного PHP-процесса, обрабатывающего один-единственный HTTP-запрос, и сумма этих последовательных обращений и составляла те самые 2-3 секунды. Ни один из 16 новых ядер эту последовательную цепочку не мог ускорить, потому что она физически исполнялась одним потоком — а частота ядра, на котором она исполнялась, стала даже чуть ниже, чем на старом сервере.

Проблему решил не апгрейд железа, а один JOIN вместо цикла из 80 запросов — время отклика упало до ожидаемых значений на том же самом «слабом» с точки зрения количества ядер сервере. Деньги, потраченные на переход на тариф с большим числом ядер, в этой конкретной задаче не принесли пользы: нужно было либо чинить запрос сразу, либо, если уж апгрейдить железо, брать сервер с более высокой частотой ядра, а не с их большим числом. Сравнение конкретных архитектур процессоров под такие задачи — в статье AMD EPYC против Intel Xeon.

Как выбирать правильно

Прежде чем смотреть на число ядер в тарифе, стоит честно ответить на два вопроса.

Какой у вас профиль нагрузки? Если это много параллельных, независимых запросов от разных пользователей одновременно (высоконагруженный магазин, API с большим числом клиентов, множество фоновых воркеров) — ядра действительно работают на вас, и тариф с их большим числом оправдан. Если это в основном последовательные операции в рамках одного запроса (типичный сайт с умеренным трафиком, тяжёлые административные операции, генерация отчётов) — важнее частота и архитектура одного ядра.

Где реально узкое место сейчас? Прежде чем платить за апгрейд, стоит измерить, а не гадать:

# Общая загрузка и разбивка по типам (user/system/iowait)
top -bn1 | head -5

# Ожидание диска отдельно от вычислительной нагрузки
iostat -x 1 5

# Медленные запросы MySQL за последний час
mysqldumpslow -s t /var/log/mysql/slow.log | head -20

Если iowait высокий — проблема в диске, и нужнее NVMe, а не ядра. Если CPU почти простаивает, а запрос всё равно долгий — проблема в сети или во внешнем сервисе. Если один процесс жрёт 100% одного ядра, а остальные свободны — это именно тот случай из мифа наоборот: не хватает не ядер, а частоты или оптимизации кода. И только если под нагрузкой утилизированы примерно все ядра сразу — тогда добавление ядер действительно даст эффект.

Частые вопросы