С чего начать диагностику? (Общий алгоритм)

Сначала необходимо убедится, что процессор загружают именно процессы сервера 1С (ragent, rmngr или rphost), а не СУБД, антивирус или что-то еще.

В Windows это можно сделать через Диспетчер задач, а в Linux с помощью утилит top или htop.

Смотрим на имя нагруженного процесса, это дает нам важную информацию для расследования. Чаще всего процессор нагружают процессы rphost, именно они выполняют серверный код конфигурации.

Далее используйте конкретные методы диагностики для каждой из возможных причин, описанных ниже.
Правильный диагноз - это 90% успеха. Удачи в расследованиях!


Основные причины высокой нагрузки на CPU и пути решения

1. Неоптимальный код

Конечно же так или иначе любая загрузка процессора вызвана каким-то кодом, но здесь речь идет именно о прикладном коде конфигурации 1С.

Краткое описание: Самая распространенная причина. Один или несколько сеансов пользователей выполняют ресурсоемкий код на встроенном языке.

Симптомы: Один или несколько процессов rphost нагружают процессор, в консоли кластера можно увидеть сеансы с высоким значением в колонке Процессорное время (текущее).

Диагностика
Для начала необходимо понять кто-же нагружает систему.
Зная PID (Process ID) процесса, можно определить кластер, в котором он работает и далее найти проблемный сеанс в одной из баз. Для этого в консоли кластера нужно зайти в раздел сеансы каждой из баз и найти сеанс с максимальным значением в колонке Процессорное время (текущее).

Следует отметить, что ситуация может быть и сложнее, нагрузку может создавать не один сеанс, а сразу несколько. В таком случае выполняем нижеследующие действия для каждого из таких сеансов, в большинстве случаев окажется что все эти пользователи работают с одним и тем же проблемным кодом.
Для расследования гораздо удобнее сразу на одном графике видеть загрузку процессора и процессорное время сеансов, такое возможно при использовании специальных инструментов, например таких как Монитор.

На графике четко видно момент времени, когда загрузка процессора стала возрастать, при этом общий график загрузки процессора и показатель Процессорное время (текущее) явно коррелируют между собой.
При клике на точку показателя Процессорное время (текущее) отображается список пользователей, у которых этот показатель не нулевой с сортировкой по убыванию. Таким образом сразу видно пользователя, который прямо сейчас нагружает процессор сильнее всего.

Когда проблемный сеанс найден, необходимо выяснить что именно он делал. Для этого можно использовать журнал регистрации вместе с анализом серверных вызовов.
Если в журнале регистрации включен уровень событий Информация, тогда в некоторых случаях можно понять, что именно запускал пользователь. Делаем фильтр по номеру сеанса и смотрим что делал пользователь во время начала высокой нагрузки.
Но, на практике к сожалению, далеко не всегда в журнале регистрации можно увидеть нужные нам события.

Более надежный источник данных - это серверные вызовы (событие CALL в тех. журнале). С помощью анализа таких событий можно понять вызов какой серверной процедуры привел к повышенной нагрузке на процессор.
Для получения таких данных нужно включать технологический журнал и анализировать события CALL с помощью bash скриптов или другими подобными инструментами.
Анализ сильно упрощается если использовать специальные инструменты, такие как Монитор, где на одном графике видны и метрики оборудования, и данные из тех. журнала 1С.
В этом случае сразу видно, что как только серверный вызов завершился, график загруженности процессора пошел вниз.

При клике на точку графика открываются подробные данные об этом вызове.

Как только мы получили стек вызова, задача переходит из разряда «Ваша 1С опять тормозит» в разряд «Вот эта конкретная обработка сильно нагружает процессор на сервере 1С».

Далее уже можно анализировать код, воспроизводить проблему под отладкой и смотреть какая конкретно строка кода или процедура вызывает проблемы, это уже прикладная задача, самое сложно во всей этой цепочке найти проблемное место.


2. Фоновые задания в базе без сеансов.

Краткое описание: Множество фоновых заданий запускаются одновременно, при этом если в базе нет сеансов это приводит к повышенной нагрузке на процессор. Сами задания выполняют оптимальный «легковесный» код, дело именно в одновременном старте большого числа заданий в базе без других сеансов.

Симптомы: CPU нагружает процесс rphost, при этом пики нагрузки совпадают по времени с началом работы фоновых заданий.


Диагностика

Даже если ни одной строчки кода в конфигурации не выполняется, процессор может быть сильно нагружен, рассмотрим, как такое может быть.
Проведем эксперимент, разместим в новом кластере 10 баз Бухгалтерия 3.0 и отключим у них все встроенные регламентные задания.
В каждой базе создадим новое регламентное задание, стартующее каждые 10 секунд, которое будет ссылаться на процедуру в которой нет ни одной строки кода.

Для чистоты эксперимента заблокируем рег. задания у всех остальных баз на этом сервере.
В результате в диспетчере задач можно увидеть следующую картину.

Синий график это общий % загруженности процессора, желтый это % загруженности процессора процессом rphost.

Из-за особенностей подсчета % загруженности процессора по процессам может превышать 100%. Для получения корректной величины нужно поделить значение на число логических ядер, в нашем случае на 8, тогда мы узнаем на сколько % в среднем этот процесс нагружает каждое ядро.

Через консоль кластера выясняем какому именно кластеру принадлежит данный процесс, для этого в консоли ищем рабочий процесс с таким же ID 22120.

Как видно на скрине выше, процесс принадлежит кластеру Доп3 в котором находится 10 наших тестовых баз.
В базах никто не работает, нет никаких сеансов, кроме одного регламентного задания, которое запускается и тут же завершается.
Тем не менее нагрузка на процессор сервера 1С создается весьма существенная, при этом есть один интересный момент, если в базах был бы хоть один активный сеанс, то повышенной нагрузки не наблюдается.
Объяснить такое поведение довольно просто, если в базе никого нет, то самый первый сеанс загружает в рабочий процесс данные информационной базы, для последующих сеансов этого не происходит.
Если же в базе запускается только одно регламентное задание, то для его запуска необходимо подгрузить данные базы, потом задание завершается и других сеансов в базе нет, следовательно рабочий процесс данные этой базы сразу выгружает. Через несколько секунд ситуация повторяется и если таких баз несколько, то постоянная загрузка/выгрузка этих данных и создает такую нагрузку на процессор.


Решение

Решение зависит от версии платформы, если используется версия 8.3.25 и выше, необходимо в консоли кластера для базы указать параметр «Задержка выгрузки конфигурации рабочим процессом» в значение большее чем интервал запуска самого быстрого задания. Данный параметр определяет через какое время (в секундах) рабочий процесс выгрузит данные информационной базы если в ней не осталось активных сеансов. Благодаря этой задержке при завершении задания данные базы останутся в памяти рабочего процесса и старт следующего задания пройдет гораздо быстрее.

Если используется платформа младше 8.3.25, тогда придется использовать различные ухищрения, например держать в каждой базе активное соединение, чтобы у рабочего процесса в кеше всегда были данные выбранной информационной базы.


3. Лицензионные ограничение платформы

 Краткое описание: Сервер 1С с лицензией ПРОФ (не КОРП!) не может использовать более 12 физических ядер (логические ядра, добавляемые технологией Hyper-Threading, не учитываются!) для серверных процессов. При высокой нагрузке, даже на мощном сервере с 32 ядрами это приводит к 100% загрузке 12 ядер, в то время как остальные простаивают.

Симптомы: Нагрузка "упирается" в потолок, мониторинг показывает, что активно работают только часть ядер. Проблема характерна для серверов с числом ядер> 12, либо для виртуальных серверов с большим числом vCPU каждый из которых имеет небольшое число ядер.

Диагностика

Проверьте нагрузку процессора с разбивкой по ядрам.

При использовании серверной лицензии ПРОФ, существует ограничение на использование только 12 ядер процессора. Таким образом если ядер больше, процессы сервера 1С их использовать не будут, в итоге может получится ситуация, когда часть ядер нагружена, а часть простаивает.

Решение

В случае выявления такой проблемы необходимо либо вынести часть нагрузки на другой сервер 1С, либо задуматься о покупке лицензии КОРП.

Данная ситуация может быть скрытой, если сервер СУБД находится на том же компьютере что и сервер 1С. В этом случае нужно собрать статистику загрузки процессора в разрезе процессов 1С и СУБД что бы понять, что из этого создает нагрузку.


4. Проблема с NUMA-архитектурой на многосокетных серверах

Краткое описание: На серверах с несколькими процессорами платформа 1С, используя один процесс rphost, работает только в рамках одного физического NUMA-узла, не распределяя нагрузку на остальные.

Основные симптомы: Проблема возникает на серверах где более двух физических CPU. По графику загрузки ядер видно, что нагружены только ядра, относящиеся к одному физическому NUMA-узлу.


Диагностика

Важно учитывать, что распределение нагрузки одного рабочего процесса идет только в пределах одного аппаратного NUMA узла. Это важно помнить если используется виртуализация.
Ниже представлен график загрузки процессора по NUMA узлам.

Решение

Для решения этой проблемы, необходимо увеличить число рабочих процессов, но и здесь не все так просто.
Желательно сделать количество рабочих процессов в 2 раза больше, чем аппаратных NUMA узлов. В нашем примере две NUMA ноды, следовательно нужно сделать минимум 4 рабочих процесса.
Управлять числом рабочих процессов в кластере можно с помощью двух настроек рабочего сервера.

1. Количество ИБ на процесс – определяет максимальное количество информационных баз, которое может обслуживать один рабочий процесс. При превышении этого количества запускается новый rphost. К сожалению, данный параметр доступен только для КОРП лицензии.

2. Количество соединений на процесс – определяет максимальное количество соединений (с ненулевым номером), которое может обслуживать один рабочий процесс. Если соединений больше, стартует новый рабочий процесс. В отличие от предыдущего данный параметр доступен как на ПРОФ, так и на КОРП лицензии.

Допустим в данном примере всего 150 соединений, из них не нулевых 120. Тогда 120 / 4 = 30. Примерно 30 соединений на процесс должно быть. Но соединений может быть чуть меньше или чуть больше, тогда постоянно буду запускаться и завершаться рабочие процессы, что приведет к излишней нагрузке на сервер.
Поэтому число соединений желательно подобрать так, чтобы не было частого перезапуска процессов. Например, в данном случае можно поставить значение 26-28, а не 30.
В любом случае после изменения значения стоит понаблюдать за системой и подкорректировать параметры в случае необходимости.


5. Обновление индекса полнотекстового поиска

Краткое описание: Частое обновление индекса полнотекстового поиска на больших базах с интенсивным изменением данных, может приводить к высокой нагрузке на CPU.

Основные симптомы: в отличие от предыдущих случаев, здесь процесс rmngr процессор, при этом в базе присутствует сеанс фонового задания обновления индекса полнотекстового поиска.


Диагностика

Данная ситуация может себя проявить в тех базах, где очень интенсивно идет изменение данных включенных в индекс ППД.
По умолчанию во всех типовых базах полнотекстовый поиск включен для всех объектов, но далеко не всем он действительно нужен, многие его просто не используют.
Обновление индекса ППД запускается каждые 60 секунд, но, если изменений было много и таких баз на сервере несколько, каждый такой запуск может вызывать всплеск нагрузки на процессор.


Решение

Сначала необходимо определится действительно ли вам нужен полнотекстовый поиск, используется ли он в вашей базе. Если нет, тогда проще всего просто его отключить с помощью стандартной обработки Управление полнотекстовым поиском.

Если же полнотекстовый поиск используется, тогда необходимо провести аудит объектов, включенных в ППД и оставить только те, где он действительно необходим. Для остальных объектов ППД необходимо отключить. Особенное внимание следует уделить регистрам.

Заключение

Загрузка процессора на сервере 1С действительно может быть неприятным сюрпризом, но причин такого поведения не так много. Для решения достаточно следовать простому алгоритму:

1. Убедитесь, что процессор нагружают именно процессы 1С (rphost, rmngr или ragent).
2. По PID процесса найдите кластер, и по данным сеанса определите пользователя.
3. Проверьте настройки регламентных заданий, если используется 8.3.25 установите параметр «Задержка выгрузки конфигурации рабочим процессом».
4. Убедитесь, что не упираетесь в ограничения лицензии ПРОФ и нет проблем с NUMA на многопроцессорных серверах.
5. Проанализируйте состав полнотекстового поиска, возможно, что он вообще не используется или большую част объектов можно из него исключить.

Системный подход, начинающийся с постоянного мониторинга и последовательного исключения возможных причин - самый быстрый путь к стабильной работе вашего сервера 1С.

Если вы хотите поделиться своим кейсом, напишите нам на support@1smonitor.ru