У одного из наших клиентов на новых и мощных серверах кластер «1С:Предприятия» демонстрировал низкую производительность, время ожидания пользователей при выполнении рабочих операций превышало все разумные пределы. Быстрый анализ показал периодический дисбаланс нагрузки между физическими процессорами — в отдельные моменты один мог быть загружен на 100%, второй на 5–10%. В статье рассказываем, как локализовали и решили эту проблему.
Общая схема работы при устранении проблемы
Забегая вперед, вот действия, которые мы выполняли при диагностировании и устранении проблемы клиента:
- Проверка платформы и конфигурации «1С:Предприятия».
- Внесение изменений в настройки платформы.
- Проверка изменений в производительности.
- Исследование аппаратного и программного комплекса у клиента.
- Поиск схожих проблем на имеющемся железе в базах знаний производителей оборудования и в публичных источниках.
- Внесение изменений в настройки аппаратного обеспечения.
Оптимизируем 1С:Предприятие
В первую очередь мы стали отслеживать поведение кластера, динамику нагрузки, ее распределения и условия, при которых проявлялась проблема снижения производительности.
Мы обратили внимание, что пик нагрузки и перекос по ней приходится на момент запуска новых процессов кластера — при подключении новых пользователей, при запуске новых процессов во время автоматической балансировки нагрузки и распределении соединений между новыми и старыми процессами. В этот момент приложение зависало на несколько минут и система была неработоспособной для тех пользователей, которые назначались на новый процесс.
Стали разбирать инцидент совместно с фирмой «1С» в рамках ИТС КОРП. В результате была выявлена ошибка платформы 30158420, зафиксированная фирмой «1С» еще в ноябре 2017 года, но не исправленная на момент возникновения сложностей у нашего клиента. По итогам переговоров с корпоративной поддержкой 1С информация об ошибке весной 2018 года была опубликована, а для нашего клиента выпустили внеочередную сборку платформы с исправлением. Вот суть ошибки:
В клиент‑серверном варианте информационной базы при одновременном запуске нескольких клиентских сеансов с одинаковым набором расширений конфигурации наблюдается избыточная нагрузка на процессор и увеличенный расход оперативной памяти.
В текущий момент ошибка исправлена в актуальных релизах платформы «1С:Предприятие».
Мы внесли изменения в платформу у клиента и проверили результат. Пользователи почувствовали улучшение ситуации, но в глобальном плане проблема сохранилась. Нагрузка все еще распределялась между двумя процессорами неравномерно:
Проверили еще несколько вариантов, приводящих к снижению производительности, в том числе давно известные — про ограничения, описанные в 2015 году о работе платформы 1С с многопроцессорными системами:
Поддержка NUMA в кластере серверов 1С полноценно пока не реализована. Сервер 1С не управляет распределением ресурсов по NUMA узлам, полностью полагаясь в этом на операционную систему, что не всегда даёт оптимальный результат. Поэтому при работе на современных многопроцессорных системах Intel и AMD, в зависимости от характера нагрузки, может наблюдаться неравномерная загрузка процессоров/ядер.
Выполнили все рекомендации по оптимизации 1С для многопроцессорных систем. Однако, к улучшению ситуации это не привело.
Настраиваем серверное окружение
Перешли к проверке системного ПО и аппаратной части вместе с ИТ‑отделом заказчика. Система построена на базе двухпроцессорной системы с 32 ядрами, по 16 на процессор.
Поиск и исследование информации о схожих с нашей задачей сложностях, материалов от поставщиков оборудования и серверной ОС дало нам три направления работы:
- Механизмы работы операционной системы на многоядерном/многопроцессорном сервере.
- Настройка аппаратной части — BIOS сервера.
- Ограничение на выполнение приложения одной группой процессоров.
Серверные операционные системы семейства Windows начиная с WinServer2008R2 64bit поддерживают работу с более чем 64 логическими процессорами на одном компьютере. Для того, чтобы это реализовать в ОС используется механизм группировки процессоров (processor group, kernel group, kgroup). Каждая из групп может содержать до 64 логических процессоров и если на сервере менее 64 логических процессоров, то должна создаваться только одна группа с порядковым номером 0. Следуя этой логике на испытуемом сервере должна быть только одна группа (Group 0), что подразумевает более‑менее равномерное распределение нагрузки между ядрами наших двух физических CPU.
Проверка аппаратной части дала пищу для размышлений. Во‑первых, нашлись кейсы, где наблюдалось падение производительности, похожее на наше, для различных приложений. В этих кейсах проводилось тестирование аналогичных серверов двух вендоров. У вендора, которого использует наш клиент, проблема была. А у иного — нет. Проблему на момент размещения кейса частично решали использованием неофициальной (unpublished) версии BIOS с добавленным в настройки параметром NUMA Group Size Optimizations.
Во-вторых, на сервере клиента использовалась устаревшая версия BIOS, для которого вендором была уже зафиксирована и исправлена ошибка, из‑за которой серверные ОС Windows могли использовать только половину или менее логических процессоров определенной линейки Intel Xeon. BIOS был обновлен до актуальной версии. В этой версии BIOS уже штатно присутствует параметр NUMA Group Size Optimization.
В-третьих, по умолчанию BIOS настроен таким образом, чтобы обеспечивать работу максимального количества логических процессоров в системе. У сервера два процессорных сокета и параметр NUMA Group Size Optimization выставлен в значение Clustered, обеспечивающее работу максимального количества ядер/процессоров. Получается, что настройка BIOS (напомним, что у сервера клиента всего 32 ядра) разбивала имеющиеся ядра/процессоры на 2 kgroup.
Получается, что в платформе «1С:Предприятие» поддержка NUMA пока не реализована и отдается на откуп ОС. ОС объединяет по умолчанию все ядра в количестве менее или равно 64 в одну группу процессоров. А на уровне оборудования выставлена настройка разбивать на несколько групп имеющиеся ядра. Явная нестыковка.
Особенность отслеживания загрузки процессоров в perfmon
Дополнительную сложность в работе принесло использование Performance Monitor Windows. В Perfmonitor есть счетчик в разделе Processor, который должен показывать общую загрузку процессоров на сервере. «1С» рекомендует этот счетчик включать. А вот Microsoft его обозначает как устаревший. При наличии нескольких групп процессоров вместо общей загрузки системы в графики и показатели попадает значение только той группы, на которой исполняется сам Performance Monitor. Ниже скриншоты. На графиках синей линией обозначены некорректные данные только по одной группе процессоров. А красной указано то, как на самом деле должен был выглядеть график. Поэтому для многопроцессорных систем не используйте неправильный счетчик в мониторе производительности.
Выводы и предупреждение
Итак, у клиента меньше 64 ядер, но BIOS сервера всё равно использовал две процессорные группы и таким образом ограничивал каждый процесс в системе лишь половиной мощностей.
При запуске нескольких процессов кластера 1С можно было бы ожидать, что они равномерно распределятся между двумя группами, но это не всегда происходило. ОС заточенная под механизмы работы NUMA‑архитектуры могла принять решение, что работать с одним процессором быстрее, чтобы использовать память адресованную для этого процессора. Получается, что несколько процессов «1С:Предприятия» оказывалось в одной группе, создавая загрузку на 100%, а вторая группа процессоров в этот момент простаивала. Очередь заданий росла, пользователи чувствовали замедление работы 1С и выказывали недовольство.
Переключение в BIOS параметра NUMA Group Size Optimization с Clustered на Flat в данном конкретном случае вернуло производительность кластера «1С:Предприятия» на должный уровень. Для пользователей пропали нестерпимые периоды ожидания и работа стала комфортной.
Но не всё так радужно. Платформа «1С:Предприятие» не умеет на момент написания статьи работать с несколькими группами процессоров. Значит, если в сервере будет установлено больше 64 ядер мы окажемся в ловушке — необходимо будет переключить в BIOS параметр NUMA Group Size Optimization в значение Clustered. А это снова вернет нас в исходную ситуацию, когда часть ядер простаивает. Фирма «1С» знает об этой проблеме и прорабатывает необходимые решения.
Отдельно стоит отметить особенности измерения общей загрузки процессора с помощью утилиты perfmon в случае использования групп процессоров, то есть на любом крупном сервере с более чем 64 ядрами.
Мы будем дальше работать над вопросами производительности информационных систем и готовы поделиться знаниями и опытом.
Обращайтесь! Высокой вам производительности и консистентности данных!
