Тюнинг производительности

Прежде чем городить multi-master или syndic, стоит выжать максимум из одного мастера — правильно настроенный, он обслуживает тысячи миньонов. Узкие места Salt предсказуемы: пул worker-процессов мастера, обрабатывающих запросы на порту 4506 (аутентификация, файлы, pillar, приём результатов), рендеринг pillar и Jinja, и лавинообразные наплывы — когда тысячи миньонов приходят одновременно после рестарта мастера или по расписанию highstate. Официальный гайд «Using Salt at scale» и справочник конфигурации мастера — два основных документа; почти весь тюнинг сводится к настройкам из них плюс дисциплина в том, как вы запускаете массовые задания.

Как это работает

Главная ручка — worker_threads: число процессов MWorker, разбирающих request-канал. Дефолта хватает для небольших парков; если миньоны ловят таймауты на state.apply при живом мастере — воркеров мало; если мастер упирается в память — много. Увеличивайте постепенно, глядя на загрузку CPU и память (каждый воркер — отдельный процесс). Вторая группа ручек — сглаживание пиков: batch-выполнение salt '*' state.apply -b 10% прогоняет задание волнами вместо всего парка разом; опция splay в расписании миньонов размазывает запуск периодических заданий случайной задержкой; random_reauth_delay и acceptance_wait_time разносят по времени переаутентификацию после рестарта мастера, гася «thundering herd». Третья группа — стоимость рендеринга: тяжёлый Jinja в SLS и объёмный pillar исполняются на каждый запрос каждого миньона; выносите дорогие вычисления из шаблонов, держите pillar компактным и адресным. Наконец, job cache: keep_jobs_seconds ограничивает срок хранения результатов, иначе каталог кеша разрастается и замедляет диск.

Когда применять

Тюнинг — первый ответ на симптомы «Salt тормозит»: массовые Minion did not respond при работающих миньонах, минутные state.apply, отвал парка после рестарта мастера. Прежде чем крутить настройки, измерьте: salt-run jobs.list_jobs покажет, что реально запускалось, нагрузка на CPU/память мастера — где предел, а salt '*' test.ping -v с увеличенным --timeout отделит «мертвых» миньонов от медленных. Правило простое: сначала убрать самодельные пики (все cron-подобные highstate в одно и то же время — классика), затем добавить worker_threads под фактическую нагрузку, и только когда вертикальный запас исчерпан — думать об архитектуре. Отдельный случай — медленные внешние зависимости: ext_pillar, ходящий во внешние API на каждый рендер, способен положить производительность мастера в одиночку.

Типичные ошибки

Первая — лечить таймауты увеличением одного лишь timeout клиента: миньоны успевают ответить, но причина (перегруженный request-канал) остаётся и растёт. Вторая — worker_threads: 100 на машине с четырьмя ядрами: воркеры конкурируют за CPU и память, становится хуже, чем было. Третья — расписание highstate без splay: каждые N минут весь парк синхронно приходит за pillar и файлами, график нагрузки мастера превращается в гребёнку. Четвёртая — гигантский pillar «на всякий случай»: он рендерится целиком под каждого миньона при каждом обновлении. Пятая — вечный job cache: спустя год каталог кеша содержит миллионы файлов, и мастер заметно тормозит на дисковых операциях — настройте срок хранения.

Как это работает

Когда применять

Типичные ошибки

Связанные понятия

Полезные ресурсы