Анатомия HighLoad в BigTech: от физики железа до архитектурных пределов

Природа HighLoad: почему классические подходы перестают работать на масштабе

Представьте ситуацию: ваш веб-сервер отлично справляется с 1000 запросов в секунду (RPS). Вы запускаете маркетинговую кампанию, трафик вырастает до 5000 RPS, и сервер внезапно "ложится". Задержки ответов (latency) вырастают с миллисекунд до десятков секунд. Вы в панике открываете утилиту htop и видите парадокс: процессоры загружены всего на 30%, а оперативной памяти свободно еще несколько гигабайт. Ресурсы есть, но система отказывается работать. Почему?

Ответ кроется в самом определении того, что такое HighLoad. Это не просто "много трафика". Это качественный переход, при котором правила игры меняются, и классические метрики перестают отражать реальное состояние системы.

Фазовый переход: от полезной работы к обслуживанию системы

В классическом веб-приложении при малых нагрузках зависимость потребления ресурсов от количества запросов линейна. В 10 раз больше пользователей — нужно в 10 раз больше тактов процессора. Однако операционная система (ОС) — это сложный механизм управления общими ресурсами.

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

Чтобы данные не повредились от одновременной записи, ядро использует блокировки (locks). Когда один поток захватывает блокировку, остальные вынуждены ждать. Чем больше потоков, тем дольше очередь. В итоге наступает момент, когда операционная система тратит больше процессорного времени на переключение контекста между ожидающими потоками и проверку блокировок, чем на выполнение полезного кода вашего приложения.

Этот фазовый переход и есть истинная природа HighLoad. Система не упирается в "железо", она упирается в архитектуру программного обеспечения и математику очередей.

Физика очередей и закон Литтла

Любой сервер под капотом — это сеть очередей. Пакеты ждут в очереди сетевой карты, потоки ждут в очереди на выполнение в CPU, запросы ждут в очереди к диску.

Поведение этих очередей описывается фундаментальным законом теории массового обслуживания — законом Литтла:

$L = \lambda W$

Где:

$L$ — среднее количество запросов, находящихся в системе (длина очереди).
$\lambda$ — интенсивность поступления запросов (например, RPS).
$W$ — среднее время обработки одного запроса.

Если время обработки $W$ остается стабильным, то при росте входящего трафика $\lambda$ очередь $L$ растет линейно. Но в условиях HighLoad из-за конкуренции за ресурсы время $W$ начинает непредсказуемо увеличиваться (потоки ждут снятия блокировок). Это приводит к лавинообразному, экспоненциальному росту длины очереди $L$ . Очереди переполняются, пакеты отбрасываются (drop), и клиент получает ошибку (тайм-аут).

Скрытые узкие горлышка

Junior-администратор при проблемах смотрит на "большую четверку": CPU, RAM, Disk I/O, Network. Senior-инженер в BigTech знает, что при HighLoad узкие горлышка смещаются вглубь операционной системы.

Если CPU простаивает, а приложение тормозит, узким местом становятся "невидимые" ресурсы:

Контекстные переключения (Context Switches). Процессор тратит драгоценные микросекунды на сохранение состояния одного потока и загрузку другого, вымывая данные из кэша L1/L2.
Прерывания (Interrupts). Сетевая карта бомбардирует процессор аппаратными прерываниями на каждый пришедший пакет, не давая ему выполнять код приложения.
Исчерпание лимитов ОС. Закончились эфемерные порты, переполнилась таблица отслеживания соединений (conntrack) или достигнут лимит открытых файлов.

Операционная система как таможня

Главная причина описанных выше накладных расходов — строгая изоляция безопасности в современных ОС. Память разделена на две зоны:

User Space (пространство пользователя): Здесь работает ваше приложение (Nginx, база данных, код на Python/Go). Оно не имеет прямого доступа к железу.
Kernel Space (пространство ядра): Привилегированный режим, где работает ядро Linux. Только оно может отправить пакет в сеть или прочитать файл с диска.

Чтобы приложение могло сделать что-то полезное (например, ответить на HTTP-запрос), оно должно попросить об этом ядро через механизм системных вызовов (syscalls).

Каждый системный вызов — это прохождение "таможни". Процессор должен остановить выполнение кода пользователя, сменить уровень привилегий, передать управление ядру, ядро проверит права доступа, выполнит работу, и затем произойдет обратный процесс.

При 100 запросах в секунду стоимость этой "таможни" незаметна. При 100 000 запросов в секунду постоянные переходы между User и Kernel space становятся главным фактором деградации. Именно поэтому в BigTech применяются технологии (такие как eBPF или DPDK), позволяющие обходить эту границу, обрабатывая пакеты прямо в пространстве пользователя или запуская пользовательский код внутри ядра.

Смена парадигмы

Понимание природы HighLoad требует изменения мышления. Вы больше не настраиваете просто "веб-сервер". Вы управляете физикой операционной системы: минимизируете переключения контекста, оптимизируете локальность данных в кэшах процессора и боретесь за каждый такт, потраченный на системный вызов.

В следующих главах мы возьмем скальпель и начнем препарировать ядро Linux, начав с того, как планировщик процессора распределяет время и почему борьба за такты порождает те самые непредсказуемые задержки.

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

Утилизация процессора на уровне 30% не гарантирует, что сервер справляется с нагрузкой. Метрика %CPU в системах мониторинга — это усреднение за секунду или даже за минуту. Если за одну секунду сервер 300 миллисекунд работал на пределе, а 700 миллисекунд простаивал, мониторинг покажет комфортные 30%. Но для запросов, которые пришли в те самые 300 миллисекунд «микроберста» (micro-burst), процессор был занят на 100%. Именно в эти доли секунды рождаются задержки, которые разрушают SLA высоконагруженных сервисов.

Анатомия очередей выполнения (Runqueue)

Ядро Linux не выполняет программы параллельно в абсолютном смысле (если потоков больше, чем физических ядер). Оно создает иллюзию параллелизма, нарезая процессорное время на микроскопические отрезки — тайм-слайсы.

Когда процесс готов к выполнению, но ядро процессора занято другим процессом, он помещается в Runqueue (очередь выполнения).

Здесь физически проявляется закон Литтла, который мы разбирали ранее. Задержка ответа сервиса ( $L$ ) складывается не только из времени фактического выполнения кода на процессоре, но и из времени ожидания в Runqueue. Чем длиннее очередь, тем дольше процесс ждет своего тайм-слайса.

В условиях HighLoad длина Runqueue становится критической метрикой. Если на 4-ядерном сервере в очереди постоянно находятся 40 готовых к выполнению потоков, каждый из них получит доступ к процессору лишь десятую часть времени. Остальные 90% времени поток будет просто ждать, хотя с точки зрения приложения он «выполняет работу».

Цена переключения контекста

Когда планировщик решает забрать процессор у потока А и отдать его потоку Б, происходит переключение контекста (Context Switch). Мы уже упоминали, что это дорогая операция на границе User и Kernel space, но теперь разберем ее физическую стоимость.

Переключение контекста имеет два вида издержек:

Прямые издержки (Direct costs): Ядро должно сохранить состояние регистров процессора, счетчик команд и указатель стека потока А в память, а затем загрузить аналогичные данные потока Б. Это занимает фиксированное время (единицы микросекунд).
Косвенные издержки (Indirect costs): Это настоящий убийца производительности. Пока поток А работал, он загрузил нужные ему данные в процессорные кэши (L1/L2). Когда начинает работать поток Б, он вытесняет данные потока А своими. Когда планировщик снова вернет управление потоку А, тому придется заново читать данные из медленной оперативной памяти.

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

Как ядро выбирает следующего: механика CFS

В современных ядрах Linux за распределение времени отвечает Completely Fair Scheduler (CFS) — полностью справедливый планировщик. Его главная цель — сделать так, чтобы все процессы получали строго пропорциональную долю процессорного времени.

CFS не использует классические очереди (FIFO) или массивы приоритетов. Вместо этого он отслеживает «виртуальное время выполнения» для каждого процесса — vruntime.

Формула расчета приращения виртуального времени выглядит так:

\Delta vruntime = \Delta t \times \frac{W_0}{W_i}

Где:

$\Delta t$ — реальное физическое время, которое процесс провел на процессоре.
$W_0$ — базовый вес процесса (соответствует стандартному приоритету nice = 0).
$W_i$ — фактический вес текущего процесса (зависит от его значения nice).

Если у всех процессов одинаковый приоритет ( $W_0 = W_i$ ), то их виртуальное время растет синхронно с реальным. Если процессу дан высокий приоритет (вес больше), его vruntime растет медленнее реального времени.

Чтобы мгновенно находить процесс, который «обделен» процессорным временем больше всего, CFS хранит все готовые к выполнению задачи в структуре данных красно-черное дерево (Red-Black Tree), отсортированном по значению vruntime.

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

Деградация под нагрузкой: когда справедливость убивает

Понимание механики CFS и стоимости контекстных переключений позволяет увидеть, как именно умирает сервер под экстремальной нагрузкой.

Допустим, в веб-сервер одновременно прилетает 1000 запросов. Просыпаются 1000 потоков-обработчиков. CFS, стремясь быть «справедливым», пытается дать каждому из них долю процессорного времени в рамках определенного окна (по умолчанию планировщик старается обойти все процессы за sysctl kernel.sched_latency_ns, обычно это от 6 до 24 миллисекунд).

Чтобы успеть обслужить 1000 потоков за 24 миллисекунды, CFS вынужден нарезать тайм-слайсы на микроскопические куски — по 0.024 мс.

Что происходит на физическом уровне:

Поток получает процессор на 24 микросекунды.
Этого времени едва хватает, чтобы загрузить данные в кэш L1.
Тайм-слайс заканчивается, происходит переключение контекста.
Следующий поток затирает кэш предыдущего.

Система сваливается в состояние Thrashing (пробуксовка). Процессор загружен на 100%, но 80% этого времени тратится на переключения контекста и ожидание данных из памяти из-за постоянных промахов в кэш. Полезная работа практически останавливается.

Именно поэтому в BigTech для критичных к задержкам компонентов (базы данных, in-memory кэши, балансировщики) используют тюнинг планировщика: увеличивают минимальный размер тайм-слайса (sched_min_granularity_ns), привязывают потоки к конкретным ядрам (CPU pinning) или вовсе изолируют ядра от планировщика ОС, отдавая их приложению монопольно.

Мы увидели, что частые переключения контекста бьют по производительности через вытеснение процессорных кэшей. Но как именно устроена память внутри процессора, почему промах мимо кэша стоит так дорого и как архитектура NUMA меняет правила игры — это фундамент, без которого невозможен анализ производительности памяти.

Память как дефицитный ресурс: иерархия кэшей и цена промаха

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

Современный процессор — это сверхбыстрый конвейер, который способен выполнять несколько инструкций за один такт. Но эта вычислительная мощь абсолютно бесполезна, если процессору не с чем работать.

Проблема стены памяти (Memory Wall)

Исторически тактовые частоты процессоров росли экспоненциально, а скорость доступа к оперативной памяти (RAM) — линейно. Возник колоссальный разрыв, известный в архитектуре ЭВМ как «стена памяти».

Чтобы понять масштаб проблемы, переведем наносекунды в процессорные такты (циклы) для типичного серверного CPU с частотой 3 ГГц:

1 такт процессора занимает $\approx 0.3 \text{ ns}$ .
Обращение к основной оперативной памяти занимает $\approx 100 \text{ ns}$ .

Это значит, что для получения одного байта из RAM процессор должен прождать около 300 тактов. Если бы процессор был человеком, который читает слово за 1 секунду, то поход за следующим словом в оперативную память занимал бы у него 5 минут.

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

Иерархия кэшей: от L1 до L3

Кэш-память делится на три уровня, балансируя между скоростью и объемом.

L1 (Level 1) — самый быстрый и самый маленький. Делится на кэш инструкций (L1i) и кэш данных (L1d). Объем обычно составляет 32–64 КБ на ядро. Доступ занимает 3–4 такта ( $\approx 1 \text{ ns}$ ).
L2 (Level 2) — промежуточный буфер, также приватный для каждого физического ядра. Объем от 256 КБ до 1 МБ (в серверных процессорах может быть больше). Доступ занимает 10–12 тактов ( $\approx 3 \text{ ns}$ ).
L3 (Level 3) — общий кэш (Last Level Cache, LLC). Он разделяется между всеми ядрами одного физического процессора (сокета). Объем исчисляется десятками мегабайт. Доступ занимает 40–70 тактов ( $\approx 15 \text{ ns}$ ).

Кэш-линия (Cache Line) Процессор никогда не читает из памяти ровно один байт. Данные всегда загружаются блоками фиксированного размера — кэш-линиями, обычно по 64 байта.

Загрузка целой кэш-линии опирается на принцип пространственной локальности: если программа обратилась к переменной, с высокой вероятностью следующая инструкция обратится к соседней ячейке (например, при обходе массива). Если нужные данные уже лежат в кэше — происходит Cache Hit (попадание), и процессор работает на максимальной скорости.

Цена промаха: CPU Stall

Когда ядро запрашивает данные, которых нет ни в L1, ни в L2, ни в L3, происходит Cache Miss (промах кэша). Запрос отправляется контроллеру оперативной памяти.

В этот момент возникает CPU Stall — остановка конвейера. Ядро физически не может продолжать вычисления текущего потока, потому что операнды для следующей инструкции еще не прибыли. В утилитах мониторинга (например, top или htop) это время будет засчитано как использование CPU (состояние running), хотя фактически процессор просто простаивает в ожидании электрического сигнала от планок RAM.

Теперь вернемся к проблеме переключения контекста из прошлой главы. Когда планировщик снимает поток с ядра и ставит туда другой, новый поток начинает обращаться к своим адресам памяти. Он вытесняет данные предыдущего потока из L1 и L2. Если первый поток вскоре возвращается на это же ядро, его кэш уже «холодный» — он разрушен соседом. Поток начинает генерировать шквал Cache Misses, и большую часть своего короткого тайм-слайса ядро проводит в состоянии CPU Stall.

Именно поэтому высокая конкуренция за процессорное время убивает пропускную способность сервера: ядра перестают вычислять и начинают ждать память.

Архитектура NUMA: когда сокетов больше одного

В BigTech высоконагруженные базы данных и гипервизоры работают на многопроцессорных серверах (2, 4 или 8 сокетов). Масштабирование упирается в физику: невозможно подключить терабайты оперативной памяти к одному контроллеру так, чтобы все ядра имели к ней одинаково быстрый доступ.

Решением стала архитектура NUMA (Non-Uniform Memory Access — неоднородный доступ к памяти).

В системе NUMA каждый физический процессор со своей локальной оперативной памятью образует NUMA-узел (NUMA node). Процессоры соединены между собой высокоскоростной шиной (например, Intel UPI или AMD Infinity Fabric).

Слово «неоднородный» означает, что время доступа к памяти теперь зависит от того, где она физически находится:

Локальный доступ: ядро обращается к памяти, подключенной к его собственному сокету. Это обычный Cache Miss ( $\approx 100 \text{ ns}$ ).
Удаленный доступ (Remote Access): ядро обращается к памяти, подключенной к соседнему сокету. Запрос должен пройти через внутреннюю шину процессора, уйти по шине UPI на другой сокет, обработаться чужим контроллером памяти и вернуться обратно. Это добавляет задержку и может занимать $\approx 150 \text{-} 200 \text{ ns}$ .

NUMA в реалиях системного администрирования

Для ядра Linux система NUMA прозрачна: оно видит единое адресное пространство. По умолчанию ядро старается выделять память для процесса в том же NUMA-узле, где этот процесс выполняется (политика local allocation).

Однако, если планировщик CFS решит балансировать нагрузку и перекинет поток с перегруженного ядра процессора №1 на свободное ядро процессора №2, произойдет катастрофа локальности. Поток окажется на новом узле, но его память останется на старом. Теперь каждый промах мимо L3 кэша будет приводить к удаленному доступу по шине UPI, увеличивая задержки в 1.5–2 раза.

Чтобы избежать такой деградации, системные администраторы используют CPU Pinning (жесткую привязку). С помощью утилит вроде taskset или numactl критически важные процессы (например, воркеры Nginx или потоки PostgreSQL) привязываются к конкретным ядрам конкретного NUMA-узла. Это запрещает планировщику перемещать их, гарантируя, что кэши L1/L2 останутся «горячими», а доступ к памяти — строго локальным.

Мы разобрались, как процессор борется за такты и ждет данные из памяти. Но прежде чем данные попадут в память, они должны прийти извне. В следующей главе мы спустимся на уровень ниже и посмотрим, как сетевая карта превращает электрические импульсы в программные структуры, и почему прерывания способны поставить на колени даже самый мощный сервер.

Сетевой стек под давлением: путь пакета и пределы прерываний

Представьте современный сервер с сетевым интерфейсом на 10 Гбит/с. Если этот канал забит короткими сообщениями (например, HTTP-запросами или метриками), сервер получает около 1.4 миллиона пакетов в секунду. Если бы ядро операционной системы обрабатывало каждый пакет как независимое событие, процессор тратил бы 100% своего времени только на то, чтобы отвлекаться от полезной работы и реагировать на прибытие данных. Сервер бы «упал», даже не начав обрабатывать бизнес-логику, при этом мониторинг показал бы полную загрузку CPU.

Мы уже знаем, как дорого обходятся переключения контекста и вытеснение процессорных кэшей. Сетевая подсистема — это главный генератор таких прерываний в HighLoad-системах. Чтобы понять, где сеть становится узким горлышком, нужно проследить путь пакета от физического кабеля до приложения в User Space.

Аппаратное прерывание: первый удар по CPU

Когда электрический или оптический сигнал достигает сетевой карты (NIC — Network Interface Controller), карта формирует из него Ethernet-кадр.

Первое, что делает умная сетевая карта — избавляет процессор от необходимости копировать этот кадр вручную. Используя механизм DMA (Direct Memory Access), NIC напрямую пишет данные пакета в заранее выделенную область оперативной памяти сервера — Rx Ring Buffer (кольцевой буфер приема).

Данные уже в памяти, но ядро ОС об этом еще не знает. Сетевая карта должна подать сигнал. Она отправляет процессору аппаратное прерывание (HardIRQ).

Логика HardIRQ безжалостна:

Процессор немедленно приостанавливает текущий поток (тот самый User Space процесс, который пытался сделать полезную работу).
Конвейер процессора сбрасывается, кэши начинают загрязняться чужими данными.
Управление передается обработчику прерываний в ядре (Kernel Space).

При нагрузке в миллион пакетов в секунду система столкнулась бы с Interrupt Storm (штормом прерываний). Процессор физически не смог бы выйти из цикла обработки HardIRQ.

NAPI: от прерываний к поллингу

Чтобы спасти процессор от шторма прерываний, в Linux был внедрен механизм NAPI (New API). Его суть — гибридный подход: переключение между прерываниями при низкой нагрузке и опросом (поллингом) при высокой.

Как это работает:

Прибывает первый пакет. NIC генерирует HardIRQ.
Ядро обрабатывает HardIRQ, но вместо того чтобы ждать следующего прерывания, оно отключает аппаратные прерывания для этой сетевой карты.
Ядро планирует программное прерывание — SoftIRQ (в процессах ОС оно часто видно как ksoftirqd).
Процесс ksoftirqd начинает в цикле (поллингом) забирать пакеты из памяти (Rx Ring Buffer), пока буфер не опустеет или пока не истечет выделенный ему тайм-слайс процессора.
Только когда буфер пуст, ядро снова включает аппаратные прерывания.

Благодаря NAPI, при 100 000 пакетов в секунду ядро может сгенерировать всего 1 000 аппаратных прерываний, собирая за один проход ksoftirqd сразу по 100 пакетов. Это радикально снижает издержки на переключение контекста.

Путь через стек: от сырых байтов до сокета

Забрав пакет из аппаратного кольцевого буфера, SoftIRQ начинает протаскивать его через сетевой стек ядра. Это тяжелая вычислительная работа.

Для каждого пакета ядро создает структуру метаданных — sk_buff (socket buffer). Сами данные пакета по памяти не копируются (это слишком дорого), передается только указатель на них.

Пакет проходит несколько уровней:

Уровень L2 (Ethernet): проверка MAC-адресов.
Уровень L3 (IP): проверка контрольных сумм, маршрутизация (Routing), правила Netfilter/iptables. Сложные правила фаервола на этом этапе могут сильно замедлить обработку.
Уровень L4 (TCP/UDP): для TCP ядро должно проверить порядковый номер (Sequence Number), обновить окно перегрузки, сформировать ACK-ответ и положить данные в правильном порядке.
Socket Receive Buffer: финальная точка в Kernel Space. Пакет ложится в очередь конкретного сокета, ожидая, пока приложение из User Space вызовет системный вызов read() или recv().

RSS: масштабирование на многоядерность

Даже с NAPI один процесс ksoftirqd, работающий на одном ядре процессора, физически не способен обработать стек TCP/IP для потока более 1-2 Гбит/с. Одно ядро упирается в 100% утилизации, пакеты копятся в Rx Ring Buffer, буфер переполняется, и сетевая карта начинает молча отбрасывать пакеты (метрика rx_dropped или overruns).

Решение — распараллелить обработку на уровне «железа». Эта технология называется RSS (Receive Side Scaling).

Современная сетевая карта имеет не один Rx Ring Buffer, а несколько аппаратных очередей (Hardware Queues). Когда пакет поступает на NIC, карта вычисляет хэш-функцию от IP-адресов и портов источника и назначения (4-tuple hash). Остаток от деления этого хэша определяет, в какую именно аппаратную очередь попадет пакет.

Каждая аппаратная очередь привязана к своему собственному прерыванию (IRQ), а каждое прерывание операционная система может привязать к отдельному ядру процессора.

Жесткая привязка прерываний конкретной очереди NIC к конкретному ядру CPU называется SMP Affinity.

Это элегантно решает проблему локальности данных:

Пакеты одного TCP-соединения всегда имеют одинаковый хэш.
Значит, они всегда попадают в одну и ту же очередь.
Значит, они всегда обрабатываются одним и тем же ядром процессора.
Следовательно, структуры данных TCP-сессии (состояние окна, таймеры) всегда остаются в L1/L2 кэше этого ядра, исключая промахи кэша и блокировки между ядрами.

Здесь сетевой стек напрямую пересекается с архитектурой NUMA (которую мы разобрали ранее). Если сетевая карта физически подключена к шине PCIe первого NUMA-узла, а прерывания RSS обрабатываются ядрами второго NUMA-узла, процессор будет вынужден гонять данные пакетов через межпроцессорную шину, увеличивая задержку (Latency) и снижая пропускную способность.

Сетевой стек Linux — это конвейер. Аппаратные прерывания бьют по процессору, NAPI сглаживает этот удар, превращая его в программную работу ksoftirqd, а RSS размазывает эту работу по доступным ядрам. Если хотя бы один этап этого конвейера не успевает за потоком, система начинает терять пакеты задолго до того, как они достигнут приложения.

Конкуренция за ресурсы: блокировки, контекстное переключение и деградация производительности

Сетевая карта принимает 10 миллионов пакетов в секунду. Технология RSS идеально размазывает прерывания по 16 ядрам процессора, ksoftirqd послушно разбирает TCP-заголовки, кэши прогреты. Но в мониторинге мы видим парадокс: утилизация CPU упирается в 100%, а пропускная способность (throughput) внезапно падает в несколько раз. Ядра процессора загружены, но они не обрабатывают трафик. Они ждут.

Идеальное распараллеливание заканчивается там, где начинается общее состояние. Независимые потоки выполнения неизбежно сталкиваются, когда им нужно обновить одну и ту же структуру данных в ядре: таблицу маршрутизации, состояние TCP-сокета или список свободных страниц памяти. Чтобы два ядра не перезаписали данные друг друга, ядро ОС использует механизмы синхронизации — блокировки.

То, как именно поток ожидает снятия блокировки, определяет, выживет ли сервер под нагрузкой или уйдет в глубокую деградацию.

Активное ожидание: Spinlock

Самый простой способ защитить данные — спинлок (Spinlock). Когда поток пытается захватить уже занятый спинлок, он не засыпает. Вместо этого он входит в бесконечный цикл, постоянно проверяя переменную в памяти: «Уже свободно? А сейчас? А теперь?».

Спинлок идеален для сверхкоротких критических секций. Если ядру нужно просто инкрементировать счетчик, соседний поток освободит блокировку за пару десятков наносекунд. Потратить несколько тактов процессора на холостой цикл (spinning) гораздо дешевле, чем снимать поток с выполнения.

Но у спинлоков есть фатальный недостаток. Если поток, захвативший спинлок, по какой-то причине задерживается (например, его прервало аппаратное прерывание HardIRQ), все остальные ядра, ожидающие этот ресурс, будут крутиться в холостом цикле. Они будут показывать 100% утилизации CPU, физически сжигая электричество, но не выполняя ни одной полезной инструкции.

Пассивное ожидание: Mutex и цена сна

Если ожидание обещает быть долгим, сжигать такты процессора недопустимо. В дело вступают мьютексы (Mutex) и семафоры.

Когда поток пытается взять занятый мьютекс, ядро ОС понимает: ждать придется долго. Поток добровольно отдает процессорное время. Планировщик CFS меняет состояние потока на TASK_UNINTERRUPTIBLE (или INTERRUPTIBLE), убирает его из Runqueue и запускает на этом ядре другой поток. Происходит контекстное переключение (Context Switch).

Контекстное переключение — это не просто сохранение регистров. Это удар по подсистеме памяти. Когда наш поток наконец дождется мьютекса и проснется, он обнаружит, что L1 и L2 кэши забиты данными того потока, который работал на ядре, пока мы спали. Начнется шквал промахов кэша (Cache Misses), и процессор будет простаивать (CPU Stall), подтягивая данные из медленной RAM.

Спираль деградации: как блокировки убивают HighLoad

Теперь мы можем собрать воедино механику коллапса высоконагруженной системы. Время ответа системы можно описать базовым соотношением:

$T_{total} = T_{exec} + T_{wait}$

Где $T_{exec}$ — время полезного выполнения инструкций, а $T_{wait}$ — время ожидания в очередях и на блокировках.

В нормальных условиях $T_{wait}$ минимально. Но при росте конкуренции (Contention) за общую структуру данных запускается цепная реакция:

Поток А захватывает мьютекс.
Потоки B, C и D пытаются получить доступ к тем же данным, натыкаются на мьютекс и уходят в сон. Происходят контекстные переключения.
Поток А завершает работу и будит поток B.
Поток B просыпается, но его кэши холодные. Из-за Cache Misses его $T_{exec}$ увеличивается в 2-3 раза.
Поскольку поток B работает дольше, он дольше удерживает мьютекс.
За это время в очередь успевают встать потоки E, F, G.

Чем дольше поток удерживает блокировку из-за холодных кэшей, тем больше других потоков успевают уснуть в ожидании. Чем больше потоков засыпает и просыпается, тем холоднее их кэши.

Это состояние глубокого Thrashing'а. Система тратит почти все ресурсы на контекстные переключения, инвалидацию кэшей и управление очередями спящих потоков. Утилизация CPU может быть высокой, но полезная работа (Goodput) стремится к нулю.

Lock-Free и RCU: чтение без ожидания

Разработчики ядра Linux прекрасно понимают цену блокировок. Если структуру данных часто читают, но редко изменяют (например, правила фаервола или таблицы маршрутизации), блокировки становятся непозволительной роскошью.

Для таких случаев в ядре применяется механизм RCU (Read-Copy-Update).

Его суть переворачивает классический подход: читатели вообще не используют блокировки. Они просто читают данные, даже если в этот момент другой поток хочет их изменить.

Как это возможно без получения битых данных?

Read: Читатели беспрепятственно обращаются к текущей версии структуры по указателю.
Copy: Если писатель хочет изменить данные, он не блокирует оригинал. Он создает полную копию структуры и вносит изменения в нее.
Update: Писатель атомарно (за одну инструкцию процессора) меняет глобальный указатель. Новые читатели теперь пойдут в новую структуру.
Старая структура остается в памяти до тех пор, пока последний «старый» читатель, начавший работу до обновления, не завершит свои операции. Только после этого память очищается.

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

Мы разобрались, как ядро пытается максимально эффективно и без блокировок обработать данные внутри себя. Но конечная цель любого сетевого пакета или прочитанного с диска файла — попасть в приложение, работающее в User Space. И на этой границе между привилегированным ядром и пользовательским кодом нас ждет следующее серьезное узкое место.

Узкие горлышка ОС: системные вызовы и границы между User и Kernel space

Пакет успешно прошел сетевую карту. Механизм NAPI уберег систему от шторма прерываний, RSS раскидал трафик по ядрам, а RCU позволил ядру обновить таблицы маршрутизации без блокировок. Данные лежат в Socket Buffer и готовы к обработке. Но графики мониторинга показывают, что приложение задыхается, а latency растет. Проблема больше не в железе и не во внутренних структурах ядра. Проблема в том, как приложение пытается эти данные забрать.

Между логикой вашего приложения и готовыми данными стоит архитектурная стена — граница между User Space и Kernel Space. Пересечение этой стены под высокой нагрузкой становится самым узким горлышком современного сервера.

Иллюзия дешевого системного вызова

В коде чтение из сокета выглядит как обычный вызов функции: bytes = recv(fd, buffer, size). Кажется, что это операция за $O(1)$ , которая просто возвращает данные. На уровне процессора это событие инициирует тектонический сдвиг.

Приложение работает в непривилегированном режиме (Ring 3). Оно не имеет права напрямую читать память ядра. Чтобы выполнить recv(), процессор должен совершить Mode Switch (переключение режима):

Выполняется специальная машинная инструкция (например, syscall в x86_64).
Процессор сбрасывает конвейер инструкций (Pipeline Flush).
Происходит смена таблиц страниц памяти (Page Tables), чтобы получить доступ к структурам ядра.
Выполняется проверка прав доступа и валидация переданных указателей.
Ядро находит нужный сокет, блокирует его структуры от изменений и начинает работу.

Переключение режима (Mode Switch) — это не переключение контекста потоков (Context Switch). Поток остается тем же, но меняются его привилегии и видимая память. Однако стоимость Mode Switch измеряется сотнями наносекунд, что при миллионах вызовов в секунду сжигает целые ядра CPU исключительно на бюрократию смены прав.

Налог на безопасность: двойное копирование

Даже когда ядро получило управление, оно не может просто отдать приложению указатель на sk_buff (структуру сетевого пакета). Память ядра защищена, и если приложение упадет или попытается изменить сырые данные, это скомпрометирует всю ОС.

Поэтому ядро вынуждено копировать полезную нагрузку из своей памяти в буфер, который приложение передало в системный вызов. Это порождает проблему двойного копирования (Double Copy).

Процессор, вместо выполнения бизнес-логики, работает как грузчик:

Читает кэш-линии из памяти ядра.
Пишет их в память User Space.

Это не только тратит такты CPU, но и вымывает полезные данные из L1/L2 кэшей. Кэш заполняется транзитными сетевыми байтами, вытесняя горячие данные самого приложения (например, хэш-таблицы сессий). Когда приложение наконец получает управление, оно сталкивается с промахами кэша (Cache Misses) при попытке продолжить работу.

Эволюция обхода стены

Исторически оптимизация HighLoad-систем сводилась к минимизации пересечений границы User/Kernel. Индустрия выработала несколько подходов, каждый из которых радикальнее предыдущего.

1. Zero-Copy: пусть ядро делает всё само

Если данные не нужно модифицировать, их можно вообще не поднимать в User Space. Классический пример — раздача статики веб-сервером (Nginx).

Вместо цепочки read(disk) -> buffer -> write(socket) используется системный вызов sendfile(). Приложение просто говорит ядру: «возьми данные из этого файлового дескриптора и переложи в этот сетевой сокет». Ядро копирует данные напрямую через DMA, минуя User Space. Приложение не касается самих байтов, экономя такты процессора и кэш.

2. io_uring: асинхронность через разделяемую память

sendfile() не работает, если приложению нужно парсить JSON, шифровать трафик или реализовывать сложную RPC-логику. Данные всё равно нужны в User Space.

Революцией в Linux стал интерфейс io_uring. Его суть — отказ от синхронных системных вызовов в пользу очередей сообщений, лежащих в разделяемой памяти (Shared Memory) между ядром и приложением.

Создаются два кольцевых буфера:

Submission Queue (SQ) — сюда приложение пишет запросы («прочитай сокет X», «запиши в файл Y»).
Completion Queue (CQ) — сюда ядро кладет результаты («прочитано 1024 байта»).

Приложение пачками (батчами) добавляет задачи в SQ и читает готовые результаты из CQ без единого системного вызова. Ядро (через отдельный поток) асинхронно забирает задачи. Граница User/Kernel больше не пересекается на каждую операцию ввода-вывода, устраняя накладные расходы Mode Switch.

Радикальные меры BigTech: сломать стену

Когда счет идет на десятки миллионов пакетов в секунду (балансировщики нагрузки, HFT-трейдинг, DPI-системы), даже io_uring становится узким местом из-за необходимости копировать данные из sk_buff ядра в буферы приложения. В этот момент архитекторы отказываются от классического ядра Linux.

Kernel Bypass (DPDK)

Технология Data Plane Development Kit (DPDK) реализует концепцию Kernel Bypass (обход ядра).

Сетевая карта физически отвязывается от сетевого стека Linux. Ядро больше не видит прерываний, не создает sk_buff и не обрабатывает TCP/IP. Вместо этого регистры сетевой карты напрямую мапятся в память User Space приложения.

Приложение запускает бесконечный цикл (Polling), который непрерывно опрашивает сетевую карту на наличие новых пакетов.

Цена Kernel Bypass:

Поток, опрашивающий карту, потребляет 100% CPU, даже если трафика нет. Это плата за нулевую задержку ожидания.
Вы теряете весь сетевой стек Linux. Придется заново реализовывать TCP/IP, маршрутизацию и фильтрацию внутри своего приложения. Утилиты вроде iptables или tcpdump перестают работать с этим интерфейсом.

eBPF: если гора не идет к Магомету

Альтернативный путь — не забирать данные в User Space, а отправить код приложения в Kernel Space.

Технология eBPF (Extended Berkeley Packet Filter) позволяет загружать безопасный, верифицированный байт-код прямо в ядро Linux. Этот код может выполняться на самых ранних этапах — например, в подсистеме XDP (eXpress Data Path), сразу после получения пакета от драйвера сетевой карты, до того как ядро выделит под него память.

Если eBPF-программа видит DDoS-пакет, она может отбросить его (Drop) за наносекунды. Если это пакет для балансировщика — изменить MAC/IP адреса и отправить обратно в сеть (Tx). И всё это — без пересечения границы User/Kernel и без аллокации тяжелых структур ядра.

Сетевой стек, блокировки, кэши и системные вызовы — это шестеренки одного механизма. Деградация в одной части неминуемо тянет за собой остальные. Чтобы найти истинную причину падения производительности, необходимо уметь сопоставлять метрики всех этих слоев воедино.