Виртуальная машина получила восемь vCPU, гостевая Linux не показывает полной загрузки, а документы 1С всё равно проводятся с задержкой. Процессорное время может забирать соседняя ВМ на том же физическом хосте.
Такую конкуренцию показывает steal time: время, когда гостевая система готова выполнять задачу, но гипервизор отдал физическое ядро другому гостю. Разработчики Linux предложили steal governor — механизм, который сокращает число предпочтительных vCPU при высоком steal time.
Пока менять рабочий сервер не нужно. Серия из 13 патчей проходит ревью и предложена для Linux 7.4 через ветку sched/core. В стабильное ядро механизм ещё не вошёл. Сейчас ваша задача — найти устойчивую связь между задержками 1С и конкуренцией за физические ядра.
Патчи для Linux 7.4 пока нельзя считать готовой функцией
Shrikanth Hegde из IBM опубликовал двенадцатую версию серии sched, steal_governor в рассылке разработчиков ядра Linux. Серия добавляет состояние preferred CPU и отдельный драйвер, который меняет набор таких процессоров по показаниям steal time.
Авторы предложили включить код в Linux 7.4. Это план, а не дата поставки. Ревью может изменить интерфейсы, пороги и сам цикл включения патчей.
В стабильных версиях Linux steal governor пока отсутствует. Нет и оснований собирать собственное ядро с этими патчами для рабочей базы 1С. У дистрибутива не будет штатной поддержки кода, который ещё меняется в рассылке ядра.
До будущего пилота проверьте базовую схему гостевой системы. Порядок установки платформы, СУБД и служб собран в руководстве по настройке ролей 1С в Linux.
Дополнительные vCPU не устраняют конкуренцию на хосте
Гостевая система считает все активные vCPU пригодными для работы. Она распределяет потоки между ними, хотя гипервизор может обслуживать эти vCPU одними и теми же физическими ядрами вместе с соседними машинами.
В результате поток теряет больше, чем несколько тактов процессора. Разработчики патчей называют ожидание блокировок, повторное заполнение кэшей и промахи TLB. Для СУБД с одновременной OLTP- и OLAP-нагрузкой такие паузы особенно заметны.
Это ещё не доказывает ускорение 1С. В описании патчей серверы баз данных названы подходящим сценарием, но испытаний платформы 1С авторы не публиковали. Поэтому механизм стоит оценивать по задержкам вашей базы, а не по чужому результату Hackbench.
| Наблюдаемый признак | Что он означает | Где искать причину | Что делать |
|---|---|---|---|
| Загрузка CPU внутри ВМ держится у предела | Гостевая система использует доступное ей процессорное время | Процессы rphost, СУБД, фоновые задания, антивирус | Найти процессы-потребители и проверить расписание тяжёлых операций |
steal time растёт вместе с задержками 1С | ВМ готова работать, но ждёт физическое ядро | Переподписка vCPU, лимиты и соседние ВМ на гипервизоре | Проверить физический пул и гарантированную долю CPU |
| 1С тормозит при спокойной загрузке гостевой ОС | Причина может находиться за границей ВМ | Хост, хранилище, сеть, лимиты виртуальной машины | Сопоставить гостевые метрики с данными гипервизора |
| Процессы закреплены через CPU affinity | Планировщик не может свободно переносить их между ядрами | Настройки служб, контейнеров и системных модулей | Проверить, нужна ли привязка и какие CPU она охватывает |
Высокий steal time ведёт к проверке физического пула. Добавлять vCPU до такой проверки опасно: новая конфигурация может усилить переподписку.
Подробный путь от симптома внутри гостевой системы до физического узла есть в схеме диагностики конкуренции за ресурсы ВМ. Она пригодится, если графики 1С и Linux сами по себе не объясняют задержку.
Как steal governor меняет выбор процессоров
Предложение состоит из двух частей. Планировщик получает маску cpu_preferred_mask, а загружаемый драйвер steal_governor меняет её по системному steal time.
cpu_preferred_mask всегда входит в cpu_active_mask. Иными словами, предпочтительные CPU остаются активными, а остальные vCPU не исчезают из виртуальной машины.
Планировщик учитывает новую маску при пробуждении задач, периодическом тике и балансировке нагрузки. Он старается размещать обычные задачи на меньшем числе предпочтительных vCPU. Так гостевая система реже претендует на физические ядра, занятые соседями.
Механизм работает постепенно. По описанию серии v12, при steal time выше 5% драйвер убирает из предпочтительного набора одно ядро. При низком значении он возвращает одно ядро обратно.
Linux Journal приводит нижний порог 2% и стандартный интервал проверки 1000 мс. В серии патчей рекомендуемый диапазон interval_ms лежит от 500 до 5000 мс. Это параметры предлагаемого кода, а не универсальные пороги исправной ВМ.
Состояние steal time | Действие регулятора | Что остаётся неизменным |
|---|---|---|
| Выше 5% | Убирает один CPU из предпочтительного набора | vCPU остаётся активным и доступным гостевой системе |
| Между 2 и 5% | Сохраняет текущую маску | Число активных vCPU и настройки affinity не меняются |
| 2% или ниже | Возвращает один CPU в предпочтительный набор | Маска не выходит за пределы активных CPU |
| Осталось одно предпочтительное ядро | Перестаёт сокращать набор | Минимум один CPU сохраняет статус preferred |
Регулятор меняет подсказку для планировщика, а не конфигурацию ВМ. Он не отключает vCPU и не уменьшает их число в настройках гипервизора.
Разберём механику на расчёте. Исходные данные: у ВМ восемь активных vCPU, интервал равен 1000 мс, а steal time остаётся выше 5%. Допустим, условие срабатывает в каждом цикле.
За три цикла предпочтительный набор сократится до пяти vCPU:
8 − 3 × 1 = 5
Переход займёт три секунды при интервале 1000 мс. Если поставить 500 мс, те же три шага займут полторы секунды. Размер шага не изменится: одно ядро за цикл.
Это расчёт поведения алгоритма, а не прогноз скорости 1С. Он не показывает, насколько быстрее пройдёт документ или запрос к СУБД.
Affinity имеет приоритет над preferred CPU
Явная привязка процесса к CPU сохраняется. Если задача закреплена только за ядром, которое регулятор пометил как непредпочтительное, Linux продолжит выполнять её там.
Так разработчики сохраняют договорённость между приложением и ядром. Preferred означает рекомендацию планировщику, а не запрет.
Перед пилотом найдите все настройки affinity. Иначе часть нагрузки не последует новой политике, а результат будет трудно объяснить. Проверять нужно параметры systemd, контейнеров, СУБД и ручные привязки процессов.
Текущий предпочтительный набор предлагается читать через:
/sys/devices/system/cpu/preferred
Интерфейс доступен только для чтения. Настраивать маску вручную через этот файл нельзя.
Сервер 1С может выиграть только при конкретном профиле нагрузки
Steal governor рассчитан на хосты с переподпиской CPU. Несколько ВМ делят физический пул, каждая видит свои vCPU и независимо реагирует на собственный steal time.
У серверной 1С есть причина попасть в группу кандидатов. Рабочие процессы и СУБД используют блокировки, общие структуры памяти и кэши. Пауза потока иногда задерживает связанные с ним задачи.
Но название класса нагрузки не заменяет испытание. Авторы проверяли код в средах PowerPC, x86 и s390. Опубликованные проценты относятся к Hackbench на PowerPC, а не к платформе 1С, PostgreSQL или MS SQL Server.
Переносить эти проценты на проведение документов нельзя. В пилоте придётся измерять длительность ваших операций: тяжёлые запросы, фоновые задания, расчёт себестоимости или закрытие периода.
Есть и обратная сторона. По описанию патчей, задачи, которым нужно максимальное чистое процессорное время, могут замедлиться. Сокращённый предпочтительный набор ограничивает пространство для их распределения.
Механизм приносит больше пользы, когда его включают у всех конкурирующих ВМ одного пула. Если регулятор работает только в гостевой системе с 1С, соседние машины продолжат занимать физические ядра прежним способом.
При выборе между физическим размещением и гипервизором пригодится сравнение двух вариантов размещения 1С. Чужие проценты из такого сравнения не заменяют замеры на вашем серверном контуре.
Что проверить до появления механизма в стабильном ядре
Начните с периода, когда пользователи замечают задержки. Снимите одновременно загрузку CPU, steal time, длину очереди, задержки диска и длительность операций 1С. Разнесённые по разным часам графики не покажут причинную связь.
Затем проверьте переподписку на физическом хосте. Нужны число физических ядер, суммарное число vCPU, лимиты, резервы и нагрузка соседних ВМ. Эти данные обычно доступны только владельцу гипервизора.
Если steal time растёт вместе с задержками, обсуждайте гарантированную долю CPU или перенос ВМ в менее занятый пул. Покупка дополнительных vCPU внутри того же перегруженного пула проблему не закрывает.
Для единого наблюдения за гостевой ОС, СУБД и платформой можно использовать панель с метриками Linux, PostgreSQL и процессов 1С. Данные гипервизора всё равно придётся добавить отдельно.
| Условие | Решение |
|---|---|
| Механизма нет в поддерживаемом стабильном ядре | Не ставить патчи на рабочую ВМ; собирать исходный профиль нагрузки |
steal time держится ниже 2% | Искать причину в процессах 1С, СУБД, диске или сети |
steal time устойчиво превышает 5% под нагрузкой | Проверить переподписку, гарантии CPU и соседние ВМ |
| Процессы закреплены через affinity | Зафиксировать привязки до пилота и учесть их при разборе результата |
| Все ВМ одного пула можно включить в испытание | После появления поддерживаемого ядра провести общий пилот на отдельном контуре |
Основание для пилота — устойчивый steal time выше порога вместе с задержками. Сам факт работы 1С в виртуальной машине ничего не доказывает.
Как провести пилот после появления поддерживаемого ядра
Для испытания нужна отдельная ВМ с копией рабочего профиля нагрузки. Рабочую базу и единственный сервер компании в эксперимент не включайте.
Авторы серии советуют собирать CONFIG_STEAL_GOVERNOR=m и не загружать модуль автоматически. Такой режим упрощает сравнение: один и тот же тест можно провести с загруженным модулем и без него.
До включения сохраните четыре группы данных:
- длительность выбранных операций 1С;
steal timeв те же интервалы;- загрузку и очередь CPU;
- список активных и предпочтительных CPU.
Повторите одинаковую последовательность операций после включения модуля. Менять одновременно число vCPU, affinity и ресурсы соседних машин нельзя: вы не поймёте, какое изменение повлияло на результат.
Пилот имеет смысл, если сократились задержки операций 1С, а не только steal time. Если регулятор уменьшил предпочтительный набор, но запросы стали дольше, для вашей нагрузки он не подходит.
Рабочий сервер сегодня оставьте без патчей. При steal time выше 5% исправляйте конкуренцию на гипервизоре: гарантируйте долю CPU, переносите нагрузку или уменьшайте переподписку.
К пилоту возвращайтесь после появления механизма в ядре, которое поддерживает ваш дистрибутив. Берите отдельную ВМ, модульную сборку и заранее записанный профиль нагрузки. При низком steal time оснований включать регулятор нет.