CPU capacity awareness становится важным тогда, когда capacity, energy model, scheduler awareness и неодинаковые ядра перестают быть фоновой деталью платформы и начинают определять доступную производительность. В такой ситуации настройка превращается не в поиск единственного нужного флага, а в управляемую проверку гипотез. Нужно знать, какой путь проходит запрос, где он получает ресурс, где ждёт и каким счётчиком это видно. Иначе даже правильный параметр прочитают как ошибку, потому что фон был слишком грязным.
Что именно нужно измерять перед изменением параметров
Первый шаг состоит в описании рабочего контура. Для CPU capacity awareness это почти всегда связка приложения, ядра, драйвера, firmware и конкретного физического пути данных. Если в документе отсутствует точный узел NUMA, слот, ядро обработчика или регион памяти, диагностика быстро скатывается к спорам. Измеряться должны latency, throughput, число повторных операций, ошибки и сам переход между состояниями.
Baseline должен быть достаточно подробным, чтобы после изменения можно было ответить на простой вопрос: что именно улучшилось и ценой чего. Полезно хранить sysinfo, конфигурацию, команду теста, версию драйвера и несколько прогонов. Для CPU capacity awareness сравнение baselines между узлами часто обнаруживает проблему раньше, чем сложный анализ одного узла.
Какие сигналы заранее показывают неудачную настройку
О неудачной настройке часто говорит не падение среднего, а изменение формы распределения. Задержка становится рваной, редкие запросы приходят пачками, повторные операции начинают расти при том же входном потоке. Для CPU capacity awareness важно смотреть и на смежные счётчики: прерывания, миграции, троттлинг, заполнение буферов и системные журналы. Одиночная метрика почти всегда врёт.
Другой ранний признак связан с восстановлением. Если после встряски системы CPU capacity awareness возвращается в работу с другой скоростью, конфигурация зависит от того, кто первым успел захватить ресурс. Это особенно неприятно в серверах с автоматическим раскатом, где одинаковая нагрузка уезжает на узлы с одинаковым на бумаге железом. На практике одинаковость нужно доказывать измерениями.
Практическая последовательность безопасного изменения параметров
Безопасное изменение строится узкими шагами. Сначала подтверждается доступность механизма, затем фиксируется привязка к топологии, потом выбирается размер рабочей порции и только потом трогается агрессивная политика. Каждый шаг должен иметь быстрый откат. Для CPU capacity awareness хороший откат значит не только возврат значения, но и подтверждение, что счётчики вернулись к baseline.
Шаги не должны быть слишком частыми. Если после каждого изменения тест занимает сорок минут, инженер начинает экономить на повторах и ошибается чаще. Лучше иметь короткий smoke набор и два длинных подтверждающих запуска. Smoke показывает грубые ошибки, а длинный запуск отвечает на вопрос о стабильности.
Команды и конфигурации, которые снимают неопределённость
Ниже приведён минимальный рабочий набор команд. Его задача состоит в том, чтобы быстро снять фактическое состояние и не опираться на предположения:
$ lscpu -e
$ cat /sys/devices/system/cpu/cpu*/cpu_capacity 2>/dev/null
$ cat /proc/sys/kernel/sched_energy_aware 2>/dev/null || true
$ perf stat -e cycles,instructions,task-clock,migrations ./load
$ turbostat --Summary --quiet sleep 10 2>/dev/null || true
$ taskset -pc 0-7 $$
$ trace-cmd record -e sched_migrate_task -e sched_wakeup ./load
Вывод команд стоит архивировать вместе с нагрузочным профилем. Если позже появится иной результат, сравнение должно быть похоже на сверку приборов, а не на угадывание. Для CPU capacity awareness особенно важно снимать состояние до и после изменения, потому что побочный эффект часто виден только в разнице.
Типичные ошибки когда оптимизация делает систему медленнее
Причины обратного эффекта обычно знакомы, но под давлением сроков их забывают:
- считать, что capacity одинакова у всех логических CPUs в одном пакете
- переносить affinity без учёта SMT и частотных ограничений
- тестировать на пустой системе и переносить вывод на систему с соседними задачами
- игнорировать влияние irq на якобы quiet ядра
Ещё одна классическая ошибка заключается в неправильной экономии. Инженер отключает удобный защитный механизм, чтобы получить цифру повыше, а через месяц эта цифра оборачивается отладкой под нагрузкой. Для CPU capacity awareness безопасность, предсказуемость и способность к восстановлению должны оцениваться вместе с пропускной способностью.
Контрольный список перед выкладкой в продуктивную среду
Перед продуктивной выкладкой используйте компактный список:
- строить карту ядер по измеренной скорости, а не по номеру;
- смотреть миграции до и после изменения scheduler policy;
- держать минимальную группу критичных потоков на стабильно сильных ядрах;
- проверять, что energy model не прячет постоянную нагрузку на слабом ядре.
При работе с CPU capacity awareness решает не столько название параметра, сколько повторяемость. Если один и тот же тест на одной системе даёт стабильный результат, а на соседней гуляет, узкое место лежит глубже приложения. Обычно это топология, привязка прерываний, прошивка или неочевидная разница в состоянии памяти.
Полезно смотреть на систему глазами обслуживающего инженера. Через полгода никто не будет помнить, почему значение выбрали именно таким. Короткая заметка рядом с конфигурацией, где указаны baseline, нагрузка и критерий отката, экономит больше времени, чем дополнительный рост средней скорости.
Для CPU capacity awareness опасен эффект почти исправной системы. Всё работает, графики гладкие, но раз в несколько дней появляется короткое окно деградации. Такие случаи ловятся длинным наблюдением и корреляцией с обновлениями, миграциями, температурой и фоновыми задачами. Быстрый тест эту картину не покажет никогда.
Хороший признак зрелой настройки состоит в том, что после изменения становится понятнее, а не быстрее любой ценой. Когда рычаг действительно нужный, повышается не только скорость, но и предсказуемость. Когда рычаг случайный, система радует один день, а потом возвращает всё с процентами в виде сложной диагностики.
Если CPU capacity awareness конфликтует с политикой безопасности, экономией энергии или ограничением виртуализации, это не всегда блокер. Часто проблема решается смещением нагрузки на другой ресурс, изменением размера буфера или разделением критичного и фонового пути. Главное состоит в том, чтобы компромисс был записан и измерен, а не выбран молча.
Заключительный критерий звучит просто: система должна вести себя одинаково после холодного старта, после тёплого прогона и после восстановления из ошибки. Если CPU capacity awareness прошёл все три состояния без сюрпризов, настройку можно считать готовой к эксплуатации.