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

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

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

Основная настройка — worker_threads, определяющая количество процессов MWorker, обрабатывающих запросы. Значение по умолчанию подходит для небольших парков. Если миньоны получают таймауты на state.apply при работающем мастере, увеличьте количество воркеров. Если мастер упирается в память, уменьшите количество воркеров. Увеличивайте постепенно, отслеживая загрузку CPU и памяти (каждый воркер — отдельный процесс).

Другая группа настроек направлена на сглаживание пиков нагрузки. Например, salt '*' state.apply -b 10% выполняет задания волнами, а не сразу для всего парка. Опция splay в расписании миньонов случайно размазывает запуск периодических заданий. Настройки random_reauth_delay и acceptance_wait_time разносят переаутентификацию после рестарта мастера, гася «thundering herd».

Третья группа настроек связана с оптимизацией рендеринга. Тяжёлый Jinja в SLS и объёмный pillar исполняются на каждый запрос каждого миньона. Выносите дорогие вычисления из шаблонов, держите pillar компактным и адресным. Наконец, настройка 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, могут значительно замедлить производительность мастера.

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

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

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

• Масштабирование и HA
• Batch-выполнение
• Конфигурация master
• Мониторинг Salt
• Pillar