Intel Resource Director обычно появляется в работе тогда, когда L3 CAT, MBA, CMT, CLOS, RMID и resctrl начинают задавать реальный предел производительности или надёжности. В этой зоне не помогает ни громкое название технологии, ни одиночный benchmark. Нужен спокойный инженерный контур: измерить путь данных, найти точку ожидания, внести одно изменение и проверить эффект без побочных изменений.
Что именно нужно измерять перед изменением параметров
Наблюдаемость для Intel Resource Director должна охватывать четыре уровня. Первый уровень это приложение и его рабочие таймеры. Второй уровень это ядро и драйвер. Третий уровень это firmware и аппаратные счётчики. Четвёртый уровень это окружающая инфраструктура: питание, температура, NUMA, соединения и очереди смежных сервисов. Если один уровень не попадает в замер, диагностика превращается в вероятностную догадку.
Baseline должен отвечать на вопрос, как система ведёт себя без изменения. Для Intel Resource Director полезно записывать не только mean и p99, но и минимум, число повторов, число ошибок, число миграций и температуру. Скучная точность здесь лучше красивой формулировки, потому что именно она потом разводит причины и следствия.
Какие сигналы заранее показывают неудачную настройку
Ранняя неудача почти всегда проявляется одинаково: среднее остаётся нормальным, а форма хвоста меняется. Редкие события становятся длиннее, повторные попытки собираются в группы, система будто дышит рывками. Для Intel Resource Director стоит смотреть также, не синхронизируются ли события с фоновой задачей, обновлением конфигурации или периодом, который к настройке вроде бы не относится.
Ещё один маркер связан со временем восстановления. Если после перезапуска сервиса Intel Resource Director ведёт себя иначе, конфигурация держится на порядке инициализации. Это плохой фундамент для эксплуатации: машины заменяются, процессы перезапускаются, коммутаторы пересчитывают маршруты. Устойчивая настройка должна переживать эти события без ручной помощи.
Практическая последовательность безопасного изменения параметров
Безопасная последовательность начинается с фиксации фактов. Нужно подтвердить, что механизм доступен, что нужные счётчики существуют и что система имеет одинаковый контур до и после изменения. Затем меняется один параметр и снимается короткий контрольный замер. Только после подтверждения эффекта можно переходить к следующему рычагу. Так работа медленнее в первый день и заметно быстрее на второй неделе.
Каждое изменение следует подписывать. В конфигурации рядом со значением нужно хранить критерий: какую метрику планировали улучшить, какой эффект ожидали и при каком результате нужно откатиться. Для Intel Resource Director это особенно важно, потому что смежные механизмы часто дают похожие симптомы, а откат не той ручки способен создать новую проблему.
Команды и конфигурации, которые снимают неопределённость
Практический набор команд для первичной диагностики выглядит так:
$ cat /sys/fs/resctrl/info/L3/cbm_mask
$ cat /sys/fs/resctrl/info/L3/num_closids
$ mkdir /sys/fs/resctrl/app
$ echo "L3:0=ff" > /sys/fs/resctrl/app/schemata
$ echo $$ > /sys/fs/resctrl/app/tasks
$ pqos -s
$ pqos -m "llc:0" -o /tmp/rdt.csv
$ perf stat -e cycles,instructions,cache-misses ./app
После съёма состояния полезно положить рядом журнал теста, вывод системного журнала и время запуска. Если позже на том же узле появится другой результат, сверка займёт минуты, а не день. Для Intel Resource Director особенно полезно сравнивать узлы парами, потому что отклонение одной машины от пула видно сразу.
Типичные ошибки когда оптимизация делает систему медленнее
Список ниже собирает причины, из-за которых разумная идея вдруг делает систему медленнее или менее предсказуемой:
- сужать маску кэша под задачу, которая упирается не в LLC, а в память
- оставлять мониторинг RMID включённым для всего подряд и платить лишней фиксацией
- изменять CLOS посреди теста и сравнивать потом смешанные интервалы
- не учитывать, что sibling thread делит ту же физическую кухню кэша
Ещё одна ошибка связана с человеческим фактором: параметр включают ради эксперимента и забывают выключить. Через несколько недель никто уже не помнит, зачем он нужен, но он продолжает влиять на путь данных. Для Intel Resource Director это неприятно, потому что поздняя диагностика обычно идёт во время инцидента, когда времени на археологию нет.
Контрольный список перед выкладкой в продуктивную среду
Перед выпуском в производство пройдите короткий перечень:
- назначать классы по роли нагрузки, а не по имени контейнера;
- снимать llc occupancy рядом с cache misses приложения;
- проверять, что ограничение MBA не давит latency sensitive класс сильнее ожидания;
- после отката маски повторять замер, а не считать откат само собой работающим.
В эксплуатации Intel Resource Director ценность измерения определяется сопоставимостью. Одинаковая команда на разных ядрах, разных прошивках и разном тепловом состоянии даёт разные цифры. Поэтому полезно фиксировать условия и не спешить с обобщением. Одна машина подсказывает гипотезу, серия машин подтверждает закономерность.
Когда настройка работает, видно не только ускорение, но и уменьшение сюрпризов. Очереди наполняются ровнее, ошибки не скачут, температура не вгоняет систему в дрожь. Если Intel Resource Director дал лучший средний результат, но график стал нервнее, выгоды, скорее всего, нет. Сервис живёт не в среднем, а в плохом процентиле.
Для Intel Resource Director стоит заранее продумать откат. Откат не означает возврат значения в текстовом файле, он означает восстановление поведения. Если после возврата счётчики не возвращаются к baseline, значит эффект задержался в состоянии драйвера, firmware или в фрагментации памяти. Это тоже измеримый результат.
При нехватке времени лучше сузить вопрос, чем расширять тест. Например, не измерять namespace целиком, если подозрение лежит в одном переходе состояния. Короткий и чистый тест даст ответ, который можно воспроизвести. Широкий тест без дисциплины даст красивую картинку без причины.
Хорошая настройка Intel Resource Director должна переживать обновление. Если небольшое обновление ядра или прошивки меняет вывод, нужно либо зафиксировать зависимость в эксплуатационной документации, либо выбрать более устойчивую конфигурацию. Скрытая зависимость от версии становится дорогой в момент неприятного инцидента.
Финальный признак зрелости простой: после изменения система становится объяснимее. Инженер может сказать, какой путь прошёл запрос, где он ждал и почему выбранное значение стоит именно таким. Если объяснения нет, то и результата нет, есть только временное совпадение условий.