Настройка ядра Linux для высоконагруженных серверов

Kernel tuning Linux: где упирается нагруженный сервер

Процессор загружен наполовину, память в запасе, а сервис всё чаще отвечает с задержкой и обрывает часть запросов по времени ожидания. Вывод «не хватает мощности» не подтверждается масштабированием: узкое место сервера оказывается не в железе, а в параметрах ядра, оставшихся по умолчанию. Настройка ядра Linux начинается с поиска места, где обрывается путь запроса, а не с правки настроек.

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

Скачущие задержки на пиках — это про планировщик задач и распределение сетевых прерываний по ядрам. Если очередь прерываний замыкается на одном ядре, оно занято разбором пакетов, приложение ждёт процессорное время, и рост числа рабочих процессов картину только ухудшает. Отдельно проверяем таблицу соединений: при её переполнении ядро начинает терять пакеты уже установленных сессий.

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

Что даёт настроенное ядро под пиковой нагрузкой

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

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

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

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

Сравнение подходов к настройке ядра

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

Что учитывать при выборе

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

Порядок работ: от снятия метрик до передачи регламента

Работу строим как один цикл: сначала измерения, потом изменения. Настройка ядра без зафиксированной базовой линии превращается в угадывание, а откат без сохранённых исходных значений — в простой на боевом контуре. Поэтому каждый этап заканчивается артефактом, который остаётся у вашей команды.

1. Аудит сервера и снятие метрик. Собираем базовую линию под реальной нагрузкой: загрузку процессоров, очереди на диск, распределение памяти, сетевые прерывания, число соединений. Замеры делаем на пике, а не в спокойные часы — иначе узкое место не проявится.
2. Поиск узкого места. Сопоставляем метрики и определяем, где теряется производительность: память вытесняется на диск, очередь ввода-вывода не успевает, обработка прерываний ложится на одно ядро.
3. Схема изменений. Фиксируем, какие параметры ядра меняем, в каких пределах и что это даёт по расчёту. Рядом — план отката и список того, что сознательно не трогаем, чтобы не платить за прирост нестабильностью.
4. Внедрение. Правки вносим частями и обратимо, исходные конфигурации сохраняем, где возможно — без перезагрузки. После каждого шага сверяемся с метриками и останавливаемся, если эффект не подтверждается.
5. Проверка на нагрузке. Прогоняем тот же профиль трафика и сравниваем до/после: время отклика, пропускную способность, поведение на пике и при отказе соседнего сервиса. Смотрим не только средние, но и хвост задержек.
6. Передача регламента. Отдаём документ: что изменено и почему, какие значения исходные, как откатывать, какие метрики и пороги держать на мониторинге. Дальше сервер ведёт ваша команда.

Конфигурации, схемы и регламенты на выходе

Настройка ядра без артефактов живёт до первого перезапуска или обновления образа — потом значения снова становятся по умолчанию, и никто не помнит, почему они были другими. Поэтому всё, что мы меняем, фиксируется в виде файлов, которые применяются автоматически, а не правятся руками на живой машине. Комплект остаётся вашей команде и работает без нас.

• Файлы конфигурации — параметры ядра, лимиты процессов и правила сетевых очередей разложены по назначению (sysctl.d, limits.d, настройки планировщика ввода-вывода), а не свалены в один общий файл, где правка одного сервиса меняет поведение остальных.
• Карта сервисов — что за процесс, какие порты и сокеты держит, к каким очередям обрабатываемых событий и дескрипторам обращается, какой службой поднимается и с чем связан по зависимостям.
• Описание лимитов — таблица «параметр — выбранное значение — обоснование — граница деградации»: видно, откуда взялось число и что изменится при сдвиге вверх или вниз.
• Инструкция по откату — пошаговый возврат к предыдущему профилю: какой файл восстановить, какую команду применить, по каким признакам убедиться, что стенд вернулся в рабочее состояние.
• Регламент обслуживания — что и с какой периодичностью проверяется, какие изменения проходят согласование, как ведётся история правок и кто отвечает за узел в дежурстве.
• Профили под роли — отдельные наборы для балансировщика, базы данных и узла приложений, чтобы правки под одну нагрузку не ломали другую.
• Скрипты применения и сверки — развёртывание конфигурации из репозитория с сохранением снимка фактических значений до и после; повторный запуск не меняет результат, расхождения видны сразу.

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

Кейс: сняли деградацию под пиковой нагрузкой

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

Деградация шла по сетевому стеку, а не по логике приложения. Доля клиентов, не дождавшихся установления соединения, выросла с 0,2% до 7%, время ответа на 99-м процентиле — вчетверо, а хвост ошибок после пика держался ещё около двадцати минут: очередь на приём не успевала рассасываться, рабочие процессы упирались в лимит дескрипторов, часть сокетов застревала в ожидании закрытия.

Настроили приём соединений под фактическую длину очереди: подняли net.core.somaxconn и tcp_max_syn_backlog, расширили диапазон локальных портов и включили переиспользование сокетов в ожидании закрытия. Дальше — fs.file-max и лимиты дескрипторов для рабочих процессов, отключённые прозрачные огромные страницы, умеренный сброс памяти вместо агрессивного swap и сетевые прерывания, разложенные по ядрам вместо обработки на одном.

Как подтвердили результат

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

Чем отличается настройка ядра Linux от типовых шаблонов?

Актуальная ветка ядра не даёт универсального набора параметров: типовые шаблоны вида «swappiness в единицу, huge pages выключить, somaxconn побольше» воспроизводят профиль нагрузки того сервиса, под который их собирали. Для приложения с длинными соединениями и холодным кэшем такой набор безвреден, а у базы с горячим рабочим набором в памяти он ускоряет дисковый ввод-вывод и раздувает хвостовую задержку.

Поэтому первым шагом идёт профиль нагрузки, а не правка параметров ядра: сколько соединений в секунду открывается и закрывается, какая доля времени проходит в ожидании сети, есть ли всплески по памяти и записи на диск. Отсюда уже видно, что трогать — очередь входящих соединений, переиспользование сокетов в состоянии TIME_WAIT, пороги сброса грязных страниц или размер huge pages.

Риски копирования в том, что часть настроек оптимизирует один сценарий за счёт другого. Отключение прозрачных huge pages снимает залипания у одних баз и добавляет накладные расходы на трансляцию адресов у других; агрессивный сброс грязных страниц укорачивает всплески записи, но бьёт по последовательным потокам. Параметр, вырванный из контекста, легко превращается в источник отказов под пиком.

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

Технические сомнения перед стартом работ

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

Нужен ли простой сервиса?

Как правило, нет: сетевые буферы, лимиты дескрипторов и планировщик ввода-вывода настраиваются без разрыва соединений. Окно требуется только параметрам загрузки ядра.

Как откатываются настройки, если стало хуже?

Изменения вносим файлом конфигурации, а не разовыми командами, поэтому откат — возврат предыдущей версии. Прежнее состояние храним, пока новый режим не переживёт пиковые часы.

Сохранятся ли настройки после обновления системы?

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

Как понять, что узкое место именно в ядре?

Начинаем с диагностики: задержки в сетевом стеке, очереди, прерывания, распределение по ядрам. Если ограничение в системных лимитах, а не в логике приложения, настройка даст эффект.

Обсудим задачу и вернёмся с оценкой и планом

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

К обращению достаточно приложить:

• Профиль нагрузки: какие сервисы живут на узле, пиковая и средняя загрузка, суточный и недельный ритм, бывают ли резкие всплески.
• Метрики за период: загрузка процессоров, ожидание ввода-вывода, потребление памяти, очереди на сетевых интерфейсах — в том виде, в каком их снимает ваша система мониторинга.
• Описание узла: ветка ядра и дистрибутив, состав оборудования или параметры виртуальной машины, тип и режим дисков.
• Схему окружения: роль узла в отказоустойчивой группе, балансировка, зависимости от соседних сервисов.
• Историю инцидентов: что именно деградировало и при какой нагрузке, какие изменения уже пробовали и к чему они привели.
• Ограничения: окна для изменений и перезагрузок, требования к доступам, правила безопасности и аудита.

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