Перейти к содержимому 
Я показываю, как Производительность ядра Linux Непосредственно влияет на время загрузки, пропускную способность и задержки в хостинговых средах, например, скорость WAN увеличилась на 38 %, а LAN - на 30 % в текущих версиях 6.x по сравнению с 5.15. Я перевожу инновации ядра, такие как HW GRO, BIG TCP и современные планировщики, в четкие показатели, чтобы заметно повысить производительность сервера. ускорить и более надежны под нагрузкой.
Центральные пункты
Чтобы сориентироваться, я кратко излагаю наиболее важные положения и отмечаю рычаги, которые я изучаю в первую очередь.
- Ядро 6.xЗначительно более быстрая сеть благодаря BIG TCP, GRO и улучшенной разгрузке.
- Планировщик процессора: Более точная синхронизация потоков уменьшает задержки для PHP, Python и баз данных.
- РесурсыNUMA, планировщик ввода-вывода и очереди сокетов предотвращают возникновение узких мест.
- ТюнингSysctl, IRQ affinity и кэширование дают ощутимый выигрыш.
- Тесты:, победы и P95/P99 обеспечивают реальный прогресс.
Моя первая ставка - на Сеть, потому что именно здесь достигается наибольший выигрыш. Затем я организую распределение процессора и памяти так, чтобы потоки ждали как можно меньше, а ядро ждало меньше. Изменение контекста создается. Для хранения данных я выбираю подходящий планировщик, проверяю глубину очереди и параметры файловой системы. Я фиксирую успех с помощью нагрузочных тестов, которые повторяю, как только меняю ядро или конфигурацию. Таким образом, я избегаю регрессий и остаюсь последовательным при каждой настройке. Целевой.
Почему версии ядра влияют на производительность хостинга
Ядро управляет Оборудование, процессов и всей маршрутизации ввода-вывода, поэтому версия напрямую определяет скорость и отзывчивость. Старые ядра 5.x остаются проверенными, но зачастую хуже используют современные сетевые карты, процессоры и стеки NVMe. В версиях 6.8 и 6.11 появились такие оптимизации, как Receiver HW GRO и BIG TCP, которые заметно повышают пропускную способность одного потока. лифт. Тесты показали прирост до 38 % в глобальной сети и 30 % в локальной сети, в зависимости от MTU и сетевой карты. Для динамических веб-сайтов с PHP, Python и Node это сокращает время выполнения одного запроса и минимизирует перегрузку очереди веб-сервера.
Особенно полезно, когда приложения отправляют много небольших ответов или часто используется завершение TLS. CPU затраты. Новый планировщик более тонко распределяет рабочую нагрузку по ядрам и повышает интерактивность при выполнении коротких задач. В то же время оптимизированные сетевые маршруты снижают накладные расходы на каждый пакет. Это приводит к более стабильным задержкам P95 и P99, которые соблюдаются поисковыми системами. Выполнение SLA экономит нервы и деньги Деньги, поскольку требуется меньше избыточных ресурсов.
Конфигурация ядра: вытеснение, тики и изоляция
В дополнение к версии Профиль сборки. Я использую PREEMPT_DYNAMIC на системах 6.x, чтобы достичь хорошего баланса между пропускной способностью и задержкой. Для действительно критичных к задержкам задач (например, TLS-прокси или API-шлюзы) можно использовать PREEMPT более быстрое реагирование, в то время как PREEMPT_NONE ускоряет выполнение больших пакетных заданий. Я также проверяю NO_HZ_FULL и изолировать отдельные ядра (isolcpus, rcu_nocbs), на которых запускаются только выбранные рабочие. Таким образом, я уменьшаю помехи от тиков планировщика и обратных вызовов RCU. Я сочетаю эту изоляцию с Сродство к IRQ, чтобы прерывания сетевой карты и связанные с ними рабочие оставались рядом с процессором.
В системах с высокой нагрузкой на прерывания я умеренно увеличиваю значение бюджета NAPI и наблюдаю, будет ли ksoftirqd занятых ядер. Если поток постоянно отнимает слишком много времени, я распределяю очереди через RPS/XPS и настраиваю IRQ coalescing. Цель - держать softirqs под контролем, чтобы потоки приложений не конкурировали за процессорное время.
Сравнение производительности: старые и новые версии ядра
Я кратко излагаю наиболее важные различия в компактном виде Таблица и дополняют рекомендации по применению. Информация основана на измерениях с MTU 1500B и 9K, которые отображают большие потоки и каналы центров обработки данных. Это помогает мне выбрать правильную версию для каждого профиля хоста. Я также обращаю внимание на то, полностью ли драйвер сетевой карты поддерживает такие функции, как GRO, TSO и RFS. Без этой поддержки улучшения в ядре иногда сходят на нет из-за накладных расходов драйвера, что приводит к потере драгоценного времени. Циклы ест.
| Версия ядра | Улучшение глобальной сети | Улучшение локальной сети | Специальные возможности | Подходит для |
|---|---|---|---|---|
| 5.15 | Базовый уровень | Базовый уровень | Проверенные водители | Наследие хостинга |
| 6.8 | +38 % | +30 % | HW GRO, BIG TCP | Высокий трафик |
| 6.11 | +33-60 % | +5-160 % | Оптимизация приемника | Интенсивная работа в сети |
Тот, кто использует BIG TCP, проверяет максимальное количество SKB_FRAGS и MTU, чтобы карта эффективно обрабатывала большие сегменты. На хостах AMD однопотоковая передача в некоторых случаях увеличивалась с 40 до 53 Гбит/с, на Intel - даже больше, в зависимости от размера пакета. Я избегаю слепого полета и провожу тестирование с идентично настроенными сетевыми картами, идентичным MTU и одинаковыми настройками TLS. Только тогда я оцениваю реальный выигрыш в зависимости от рабочей нагрузки. Так я выбираю версию, которая лучше всего подходит для моего профиля хоста на практике. обслуживает.
Планирование процессора и NUMA: реальный эффект под нагрузкой
От распределения процессора зависит, будут ли потоки работать гладко или нет. запустить или постоянно ждать. Современные ядра 6.x лучше приоритизируют короткие задачи и снижают пики задержек для веб-серверов и прокси-серверов. Балансировка NUMA имеет значение на хостах с несколькими процессорными гнездами, иначе обращения к памяти слишком часто оказываются на других узлах. Я подключаю IRQ и важные рабочие устройства к соответствующим ядрам, чтобы сохранить локальность кэша. Для более подробного ознакомления обратитесь к компактной статье Статья NUMA, что облегчает мне составление карты процессора, оперативной памяти и рабочей нагрузки.
Под высоким Загрузить Стоит использовать cgroups v2, чтобы отлавливать шумных соседей и гарантировать справедливое время работы процессора. Я также проверяю настройки irqbalance и при необходимости устанавливаю аффинити вручную. Базы данных выигрывают, когда планировщик не позволяет длинным транзакциям конкурировать с короткими веб-запросами. Я слежу за количеством контекстных переключений и сокращаю их за счет пула потоков и уменьшения числа рабочих. Такие меры стабилизируют задержки P95 без необходимости установки оборудования. пополнять.
Управление питанием: Turbo, C-States и Governor
Производительность и Режимы энергосбережения сильно влияет на задержку. Обычно я выбираю регулятор „производительность“ на путях задержки или устанавливаю агрессивную "производительность" для intel_pstate/amd-pstate. энергетическая_эффективность_предпочтений. Хотя низкие C-состояния ограничивают потребление, они вызывают дрожание при пробуждении. Я ограничиваю C-состояния для фронт-эндов, в то время как пакетные задания могут сохранять больше. Важно, что я измеряю этот выбор: лучшие значения P95 часто оправдывают немного большее энергопотребление.
Я использую Turbo Boost выборочно, но слежу за температурными и мощностными ограничениями. Когда дросселирование вступает в силу, тактовая частота падает именно во время пиков нагрузки. Я регулирую пределы охлаждения и энергопотребления, чтобы хост получал время ускорения там, где это выгодно моему приложению.
Сетевой стек: BIG TCP, GRO и контроль перегрузок
Сеть предоставляет наибольшие возможности для достижения ощутимых результатов быстрее Страницы. BIG TCP увеличивает размеры сегментов, GRO объединяет пакеты и уменьшает накладные расходы на прерывания. RFS/XPS разумно распределяет потоки по ядрам, чтобы увеличить количество обращений к кэшу. В сценариях с широкозональным трафиком я принимаю осознанное решение об управлении перегрузками, обычно это CUBIC или BBR. Если вы хотите разобраться в различиях, подробности можно найти в этом обзоре Управление перегрузками TCP, который хорошо обобщает эффект задержки.
Я начинаю с последовательного sysctl-значения: net.core.rmem_max, net.core.wmem_max, net.core.netdev_max_backlog и tcp_rmem/tcp_wmem. Затем я тестирую с одинаковым MTU и одинаковым набором шифров TLS, чтобы сравнить Apple с Apple. На многопортовых картах я проверяю RSS и количество очередей, чтобы убедиться, что все ядра работают. Если разгрузка, например TSO/GSO, приводит к падениям, я деактивирую ее специально для каждого интерфейса. Только когда я вижу чистые кривые измерений, я распространяю конфигурацию на другие интерфейсы. Хозяева от.
IRQ Coalescing, Softirqs и подробности о драйверах
С умеренным Коалесцирование IRQ Я сглаживаю задержки и уменьшаю штормы прерываний. Я начинаю консервативно и постепенно увеличиваю пороги микросекунд и пакетов, пока падения не уменьшатся, но P95 не пострадает. При очень маленьких пакетах (например, gRPC/HTTP/2) слишком большое сглаживание замедляет работу, тогда я отдаю предпочтение времени отклика. Я контролирую softirq-времени, падений пакетов и netdev-backlogs. Если ksoftirqd постоянно потребляет CPU, то баланс между очередями RSS, RPS/XPS и коалесценцией часто оказывается неправильным. Тогда я использую XPS для более точного распределения потоков по ядрам, на которых также находятся соответствующие рабочие.
Я проверяю такие функции драйвера, как TSO/GSO/GRO и выгрузка контрольной суммы для каждой сетевой карты. Некоторые карты дают огромный выигрыш при использовании HW-GRO, другие больше выигрывают от программных путей. Важно: я сохраняю MTU согласован на всем пути. Большое MTU на сервере не принесет пользы, если коммутаторы или одноранговые сети сократят его.
Пути хранения и ввода-вывода: от планировщика до файловой системы
Многие страницы теряют скорость при ВВОД/ВЫВОД, не в сети. NVMe нуждается в подходящем планировщике ввода-вывода, иначе хост отдает пропускную способность и увеличивает пики задержек. Для HDD/гибридных систем BFQ часто обеспечивает лучшую интерактивность, в то время как mq-deadline обеспечивает более стабильное время работы с NVMe. Я тестирую глубину очереди, readahead и параметры файловой системы, такие как noatime или настройки барьеров. Если вам нужна справочная информация, обратите внимание на это компактное руководство по Планировщик ввода/вывода, который классифицирует эффекты с практической точки зрения.
Я перевожу резервные копии и задания cron в бесшумный режим. Временные интервалы, чтобы не допустить столкновения с производственной нагрузкой. Я также изолирую журналы баз данных на своих собственных устройствах, если это возможно. Для ext4 и XFS я тестирую параметры монтирования и проверяю режимы работы журналов. Я использую iostat, blkstat и perf для быстрого выявления "горячих точек". В результате время отклика сокращается, потому что ядро меньше блокирует, а приложение работает непрерывно. работает.
io_uring, управление нулевым копированием и записью
Я использую современные ядра io_uring для асинхронных рабочих нагрузок ввода-вывода. Веб-серверы, прокси-серверы и конвейеры обработки данных выигрывают, поскольку системные вызовы объединяются, а переключение контекста сокращается. При отправке больших файлов я использую пути с нулевым копированием (sendfile/splice или SO_ZEROCOPY), поскольку они взаимодействуют со стратегией TLS и разгрузкой. Я измеряю, снижается ли нагрузка на процессор и остаются ли стабильными задержки при высоком параллелизме.
Я управляю записью и кэшем страниц с помощью параметров vm.dirty_*. Слишком большая грязная очередь ускоряет фазы записи и задерживает смыв; слишком маленькие значения, напротив, вызывают частые синхронизации и замедляют работу. Я выставляю окно, соответствующее конфигурации моего SSD/RAID, и проверяю задержки P95 во время интенсивных фаз записи.
Настройка сервера: специфические параметры ядра
После обновления я настроил несколько, но эффективных Переключатели. В сети я начинаю с net.core.somaxconn, tcp_fastopen, tcp_timestamps и net.ipv4.ip_local_port_range. Для многих соединений помогает более высокий net.core.somaxconn и подходящая очередь отставания в веб-сервере. Что касается памяти, то умеренная vm.swappiness снижает количество неуместных выселений, hugepages нуждается в четких тестах для каждого приложения. С помощью инструментов htop, psrecord, perf и eBPF я вижу узкие места раньше клиентов. запомнить.
Для измерений я использую sysbench для процессора, памяти и ввода-вывода и сравниваю 5.15 с 6.x с идентичными параметрами. Конфигурация. Apache Bench и Siege обеспечивают быструю проверку: ab -n 100 -c 10, siege -c50 -b. Очень важны воспроизводимые условия, то есть одинаковое рукопожатие TLS, одинаковая полезная нагрузка, одинаковый статус кэша. Я постепенно увеличиваю продолжительность теста и параллелизм, пока не найду точки разрыва. Затем я защищаю результат, документируя все изменения и создавая пути отката. быть готовым.
TLS, криптографическая разгрузка и kTLS
Значительная часть времени процессора уходит на TLS. Я проверяю, поддерживают ли мои процессоры криптографию AES-NI/ARMv8 и используют ли ее провайдеры OpenSSL. При высоком параллелизме возобновление сеанса и сшивание OCSP приносят заметное облегчение. kTLS снижает накладные расходы на копирование на пути к ядру; я проверяю, выигрывает ли от этого мой веб-сервер/прокси и надежно ли работает нулевое копирование с TLS. Важно: поддерживайте согласованность наборов шифров, чтобы бенчмарки были сопоставимы.
Наблюдаемость: eBPF/Perf-минимум для повседневной жизни
Я работаю с небольшим, повторяющимся Набор для измеренияperf stat/record для профилирования процессора, tcp- и биолатентность-инструменты eBPF для распределения сети/хранилища, а также тепловые карты для длины очереди выполнения. Это позволяет мне быстро определить, что преобладает: мягкие ошибки, системные вызовы, блокировки или доступ к памяти. Когда я устраняю узкие места, я повторяю тот же набор, чтобы выявить побочные эффекты. Только когда кривые CPU, NET и IO выглядят чистыми, я расширяю конфигурацию.
Правильно оценивайте нагрузочные тесты
Я проверяю не только средние значения, но и прежде всего P95 и P99. Эти ключевые показатели показывают, как часто пользователи сталкиваются с заметным временем ожидания. Рост числа ошибок указывает на истощение потоков или сокетов. В случае Load Average я обращаю внимание на то, что он отображает очереди, а не чистый процент CPU. Ожидание Aio или базы данных также увеличивает значение Топ.
В реалистичном тесте используется та же стратегия кэширования, что и в производстве. Я начинаю с холодного, измеряю теплый, а затем записываю более длительные фазы. Одного RPS мне недостаточно; я связываю его с задержкой и состоянием ресурсов. Только общая картина показывает, насколько хорошо ядро и параметры настройки работают вместе. Таким образом, я гарантирую, что улучшения будут заметны не только в синтетических бенчмарках. блеск.
Виртуализация: кража времени и накладных расходов
Замедляет работу на общих хостах Украсть Время спокойно отключает производительность. Я отслеживаю значение на vCPU и только потом планирую параллелизм своих служб. Если время угона велико, я переключаюсь на выделенные экземпляры или повышаю приоритет гостя. В гипервизоре я последовательно распределяю vCPU по узлам NUMA и фиксирую IRQ важных сетевых карт. Я не уменьшаю контейнеры вслепую, а оптимизирую лимиты, чтобы ядро могло чисто принимать решения по CFS. знакомьтесь: Может.
Виртуальные сетевые карты, такие как virtio-net, выигрывают от более современных Драйверы и достаточное количество очередей. Я также проверяю, активна ли vhost-net и стабильно ли правильное MTU. На стороне хранилища я проверяю параметры paravirt и глубину очереди. При высокой плотности я увеличиваю частоту мониторинга, чтобы быстрее заметить скачки. Все это предотвращает потерю хороших функций ядра в накладных расходах на виртуализацию. засыпать песком.
Контейнерные рабочие нагрузки: Правильное использование Cgroup v2
Для микросервисов я полагаюсь на cgroup v2-контроллеры: cpu.max/cpu.weight контролируют справедливость, memory.high защищает хост от штормов вытеснения, а io.max ограничивает мешающие записи. С помощью cpuset.cpus и cpuset.mems я поддерживаю пути с латентностью, близкой к NUMA. Я документирую лимиты для каждого класса сервисов (веб, БД, кэш) и сохраняю свободное пространство, чтобы не возникало каскадных эффектов, если какому-то сервису на короткое время потребуется больше.
Выбор дистрибутива: периодичность и поддержка ядра
Распределение определяет, как быстро Ядро-обновления становятся доступными и как долго исправления доставляются. Debian и Rocky/Alma предоставляют долго поддерживаемые пакеты, идеальные для спокойных систем с предсказуемыми изменениями. Ubuntu HWE предлагает более молодые ядра, что делает драйверы и функции доступными раньше. Gentoo позволяет производить тонкую настройку вплоть до набора инструкций, что может дать преимущества для специальных хостов. Я принимаю решение в зависимости от профиля рабочей нагрузки, окон обновлений и требований моего Клиенты.
Разумное обновление начинается на промежуточных узлах с идентичным оборудованием. Я проверяю источники пакетов, безопасную загрузку и модули DKMS, такие как ZFS или специальные драйверы сетевых карт. Затем я фиксирую версии ядра, чтобы избежать неожиданных скачков. Для производительных систем я планирую окна обслуживания и чистый откат. Так я сочетаю новые возможности с высокими Планируемость.
Безопасность и техническое обслуживание без потери скорости
Патчи безопасности могут не Производительность не оказывают длительного воздействия. Я использую "живые" исправления, где это возможно, и тестирую такие средства защиты, как spectre_v2 или retpoline, на предмет их влияния. Некоторые хосты заметно выигрывают, когда я выборочно отключаю функции, которые не приносят никакой пользы в конкретном контексте. Тем не менее, безопасность остается обязательством, поэтому я принимаю осознанные решения и документирую исключения. В профиле каждого хоста должна быть четкая грань между риском и безопасностью. Скорость.
Я регулярно обновляю ядро с помощью регрессионных тестов. Я сохраняю профили производительности до и после обновления и сравниваю "горячие точки". В случае обнаружения отклонений я откатываюсь назад или использую альтернативные минорные версии из той же серии. Я сохраняю логи, чтобы они не становились узким местом под нагрузкой. Это позволяет поддерживать доступность, безопасность и производительность на должном уровне. Баланс.
Краткое резюме и план действий
Поднимите текущее ядро 6.x Сеть и планирования; мои первые шаги - это BIG TCP, GRO, RFS/XPS и чистые значения sysctl. Затем я обеспечиваю близость процессора с помощью IRQ affinity и NUMA mapping и выбираю подходящий планировщик ввода-вывода для хранения данных. С помощью ab, Siege и sysbench я проверяю прибыль, сравнивая RPS с P95/P99. Если кривая чистая, я контролируемо расширяю конфигурацию и версию ядра. Так я уменьшаю задержки, увеличиваю пропускную способность и поддерживаю время отклика ниже трех. Секунды.
Мой практический план действий таков: 1) Обновление до версии 6.8+ или 6.11 с подходящими драйверами. 2) Настройте сетевой стек и выберите подходящий контроль перегрузки. 3) Организуйте CPU/NUMA и IRQ, затем протестируйте очереди хранения и опции файловой системы. 4) Повторите нагрузочные тесты с идентичными параметрами, изменениями версий и документов. Те, кто поступает подобным образом, используют Linux Ядро постоянно обновляется и позволяет получить удивительно много от существующего оборудования.
