CPU Pinning і ізоляція ядер: знижуємо jitter до 50 мкс на практиці

CPU Pinning: чому сервіс смикається під піковим навантаженням

Поки сервіс недовантажений, відгук рівний — і це заколисує. На піку одні й ті самі запити обробляються то швидко, то помітно довше, хоча середнє завантаження процесорів далеке від межі. Справа зазвичай не в нестачі потужності, а в тому, як ядра розподіляються між робочими потоками.

Планувальник задач не знає, які потоки працюють у зв'язці, і вільно переносить їх між ядрами. Кожне перенесення — втрата прогрітого кешу й зруйнована локальність пам'яті, а разом із ними й передбачуваність відгуку.

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

CPU Pinning та ізоляція ядер прибирають цю невизначеність на рівні операційної системи. Ключові потоки закріплюються за виділеними ядрами й більше не мігрують, а службові процеси виносяться на решту — планувальник перестає зіштовхувати прикладне навантаження з фоновими задачами.

Ядро залишається прогрітим, і час обробки перестає залежати від того, що ще відбувалося на машині в цей момент.

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

Що дає закріплення ядер: рівний відгук і передбачуваність

Планувальник ядра за замовчуванням балансує навантаження й переносить потоки між процесорами, щоб завантаження було рівномірним.

Для сервісів із жорсткими вимогами до часу відповіді це обертається дрижанням затримки: потік потрапляє то на «гаряче» ядро, то на щойно звільнене, втрачає теплий кеш і чекає своєї черги.

Закріплення ядер прив'язує робочі потоки та їхні обробники переривань до фіксованого набору — міграції припиняються, а розкид часу обробки падає з мілісекунд до десятків мікросекунд.

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

У ядрі Linux це робиться штатними засобами, тому конфігурація відтворювана й переноситься між серверами однієї ролі без пропрієтарних патчів.

Змінюється не середня затримка, а її хвіст. За закріплення та ізоляції квантилі високого порядку перестають стрибати під піком: час обробки запиту на 95-му й 99-му процентилі наближається до медіани, і поведінка сервісу передбачувана.

Саме цей сценарій — конкуренція за ресурс — дає класичний клас відмов: формально вільні потужності є, а частина запитів іде в таймаут через «украдений» час процесора.

Звідси вимірюваний ефект. Ємність планується за стабільними метриками, а не із запасом «на шум»; відпадає потреба тримати зайві репліки лише заради гасіння стрибків.

Стендові вимірювання починають збігатися з продакшеном — зниження затримки підтверджується повторювано, а не разово.

Схеми закріплення: виділені ядра, спільні та гібридні

Вибір схеми закріплення — це компроміс між передбачуваністю затримок і утилізацією заліза.

На одному хості зазвичай живуть і критичний до відгуку сервіс, і звичайні задачі, тому важливо не «закріпити все», а рознести за групами: що отримує гарантоване ядро, що ділити в загальному пулі, а що тримати в запасі.

Ізоляція від службових процесів

Саме закріплення без ізоляції дає мало: якщо у виділене ядро й далі приходять обробники переривань, таймери та системні потоки обслуговування, jitter повертається.

Тому маску закріплення доповнюють виключенням ядер із загального планування й явною прив'язкою переривань до службової групи — тоді критичний потік отримує передбачувані десятки мікросекунд розкиду замість мілісекундних сплесків.

Практичний критерій вибору — виміряний розкид затримок під піковим навантаженням, а не догма. Розумний порядок: почати з м'якого закріплення, зняти профіль, і лише якщо гістограма затримок не вкладається у вимогу — переходити до виділених ядер і гібридної розкладки.

Як ми впроваджуємо CPU Pinning: від вимірювання до передачі

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

Будь-яке налаштування без базового вимірювання — ворожіння: незрозуміло, що саме дало ефект і що зламається в наступному релізі. Нижче — порядок, за яким ми ведемо CPU Pinning від першого стенда до передачі супроводу.

1. Вимірювання поточної поведінки. Знімаємо профіль затримок за цільовим сценарієм: розподіл часу відгуку, 99-й процентиль, тривалість найгірших викидів, частоту перемикань контексту й міграцій задач між ядрами. Результат — базовий зріз, із яким порівнюємо все подальше.
2. Проєктування схеми розподілу ядер. Визначаємо, які ядра віддаємо застосунку, які залишаємо під систему, обробку переривань і службові потоки. Враховуємо топологію NUMA та спільні кеші, щоб потоки не конкурували за одну пам'ять.
3. Налаштування ізоляції. Вносимо параметри ізоляції ядер і маски спорідненості, виносимо обробники переривань на виділені ядра, вимикаємо енергозбережувальні режими, які додають розкид. Зміни оформлюємо як конфігурацію, а не ручні правки на живій машині.
4. Перевірка під навантаженням. Проганяємо цільовий профіль у піковому та змішаному режимі: дивимося, що розкид затримок тримається за зростання числа з'єднань, і перевіряємо, що системні процеси не голодують на решті ядер.
5. Перевірка відкату. Переконуємося, що схема знімається поверненням конфігурації без перезбирання вузла, і що деградація за зняття ізоляції передбачувана — це страховка на час інцидентів.
6. Передача супроводу. Віддаємо схему розподілу, конфігурації, метрики й пороги спрацювання, регламент змін планувальника та коротку інструкцію для чергової зміни.

Кожен етап закривається артефактом і вимірюванням, а не усним «стало краще» — тому ефект від налаштування видно в цифрах, а не у відчуттях.

Що залишається у вашої команди після налаштування ізоляції

Налаштування ізоляції закінчується не фактом «перенесли навантаження на виділені ядра», а комплектом, із яким ваша команда далі працює сама. Усе, що ми змінюємо на вузлах, фіксується файлами у вашому ж репозиторії: конфігурації, схеми, регламенти й порядок перевірки.

Потрібен такий комплект тому, що розподіл ядер ламається тихо — нова служба на вузлі або оновлення системи зсуває прив'язки, і розкид затримок повертається до початкового.

• Конфігурації ядер. Робочі файли параметрів завантаження й налаштувань служб для кожного класу вузлів, із коментарями: які значення критичні, що станеться, якщо їх виправити, і які рядки чіпати не можна.
• Схема розподілу ресурсів. Карта прив'язок: скільки ядер віддано в ізольований набір, скільки залишено під систему та службові задачі, як це розкладено за конкретними вузлами й ролями.
• Регламент обслуговування. Порядок планових робіт: що перезапускається на ходу, що потребує виведення вузла з роботи, і як переконатися, що після оновлення прив'язки на місці.
• Документація по вузлу. Паспорт кожного вузла: роль, склад ізольованого набору, задіяні служби, власник із боку вашої команди й точка звернення за відхилення.
• Порядок перевірки змін. Контрольний список перед викаткою: зняття базових вимірювань, порівняння з еталоном, критерій, за якого зміну відкочують без обговорень.
• Набір вимірювань і шаблони. Скрипти зняття метрик затримок і еталонні значення по кожному вузлу — за ними відхилення видно без нашої участі.

Комплект прив'язаний до ваших конфігураційних репозиторіїв і системи контролю версій, а не до наших внутрішніх записів. Через пів року новий інженер розбереться за цими файлами швидше, ніж за листуванням.

Кейс: як прибрали просідання відгуку на навантаженому вузлі

Що було до змін

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

Планувальник вільно переносив потоки між ядрами, кеш охолоджувався, і під піком розкид затримок сягав сотень мікросекунд.

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

Що змінили

Критичні обробники закріпили за виділеним набором ядер, службові процеси — за окремим, міграцію потоків між ними вимкнули. З ізольованих ядер зняли обробку переривань і періодичні задачі ядра, перевівши їх на службову частину.

На вузлі з Kubernetes розвели діапазони ядер для робочих і системних навантажень, щоб поди з фоновими задачами фізично не потрапляли на закріплені ядра.

Що стало за вимірюваннями

• Розкид затримок обробників скоротився із сотень мікросекунд до десятків, дев'яносто дев'ятий перцентиль перестав вибиватися з основного розподілу.
• За десятиразового зростання навантаження хвіст виріс на десятки відсотків замість кратного зростання — поведінка під піком стала передбачуваною.
• Частка запитів, що не вклалися в ліміт часу, скоротилася на порядок, повторні спроби перестали додавати навантаження.
• Перезбирання індексу йде паралельно з обробкою запитів без просідання відгуку.

Чим ізоляція ядер відрізняється від пріоритизації процесів?

Пріоритизація процесів змінює лише порядок доступу до процесора: планувальник Linux видає задачі більшу вагу, її раніше ставлять у чергу й рідше витісняють.

Але конкуренція за ядро залишається — під навантаженням потік усе одно ділить його із сусідами, переїжджає між ядрами й скидає кеш. Саме ці перемикання та міграції дають той самий розкид відгуку, який потім ловлять як рідкісні піки затримки.

Ізоляція ядер прибирає не черговість, а саму конкуренцію. Ядра виводяться із загального пулу планувальника, сторонні задачі туди не допускаються, і критичний потік отримує виділений майданчик повністю.

Перемикань контексту майже не залишається, міграція заборонена, а отже дрижання затримки перестає залежати від того, чим зайнята решта машини.

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

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

На практиці ми застосовуємо обидва рівні разом: пріоритетами розводимо фонові та користувацькі задачі, ізоляцією захищаємо критичні обробники — мережеві, шифрувальні, потоки обміну із зовнішніми системами.

Виділені ядра фіксуються в конфігурації машини як код, щоб поділ ресурсів не губився під час перезапуску й переносився на новий вузол без ручної правки.

Часті технічні сумніви перед впровадженням

Перед впровадженням команди ставлять одні й ті самі запитання: чи не постраждають сусідні сервіси, що робити з уже розгорнутим розподілом навантаження, як відкотити зміни. Розбираємо кожне — це і є основна частина роботи, а не сама прив'язка ядер до процесів.

Ізоляція виводить частину ядер із загального планувальника, тому її закладають із запасом: знімаємо профіль завантаження, закріплюємо по одній групі й стежимо за затримками в сусідів. Розкладка зберігається декларативно під контролем версій — відкат повертає попередній стан системи.

У нас уже розгорнуто розподіл навантаження — доведеться все переробляти?

Ні. Прив'язка задається точково для процесів із вимогою до передбачуваного відгуку, через штатні групи керування планувальника. Інші сервіси продовжують працювати за поточною схемою.

Як відкочуються зміни, якщо стане гірше?

Параметри розкладки версіонуються: відкат — це повернення попереднього набору й повторне застосування. Процеси повертаються назад у загальний планувальник, а тригери відкату прописані заздалегідь — зростання затримок, просідання пропускної здатності.

Що входить у супровід після налаштування?

Залишаємо спостережуваність: затримки по кожному закріпленому ядру, оповіщення про вихід за поріг, інструкції для власників сервісів. Розкладку переглядають за зростання навантаження — інакше ізоляція поступово втрачає ефект.

Обговоримо задачу: повернемося з оцінкою та планом робіт

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

Нижче перелік того, що варто надіслати заздалегідь; якщо частини даних немає, зберемо її самі на вашому стенді, але це подовжує підготовку оцінки.

• вивід lscpu з повною топологією та розбивкою за вузлами NUMA — за ним видно, які ядра ділять кеш і шину;
• список процесів і сервісів, яким потрібен жорсткий бюджет затримки, з поточними метриками: медіана, p99, максимум і частка викидів;
• поточну розкладку переривань і мережевих черг за ядрами — що прив'язано вручну, що залишилося на irqbalance;
• вимогу до залишкового jitter і допустиму деградацію під піковим навантаженням;
• конфігурацію віртуалізації або контейнерів: ізоляція ядер на хості, проброшення в гостя, ліміти планувальника;
• вікно робіт, допустимість перезавантажень і наявність резервного вузла для перемикання;
• доступ до стенда, що повторює бойовий профіль навантаження, — інакше цифри до/після не можна порівнювати.

За цими даними рахуємо, скільки ядер іде під ізоляцію, які задачі переносимо на системний набір, де знадобиться перерозкладка переривань і чи потрібні окремі політики для гостей.

Оцінка приходить разом із планом впровадження: порядок змін, точки відкату, метрики приймання на кожному кроці.

Опишіть задачу й долучіть те, що є, — повернемося з оцінкою робіт і планом впровадження під ваш профіль навантаження.