Как выявить повышенную загрузку процессора на сервере 1С 

Александр Рудницкий

Программист 1С компании CorpSoft24

Стандартный вызов при администрировании систем 1С – проблема отношений между процессором сервера (CPU) и рабочим процессом rphost.exe, который обслуживает клиентские обращения и взаимодействует с сервером базы данных. Нередко они становятся причиной перегрузок CPU, что приводит к замедлению и сбоям работы. Разбираемся, как выявлять такие случаи и что делать для их профилактики и устранения.

Начнём с того, что rphost представляет собой ключевое звено всей архитектуры 1С, забирая на себя большую аппаратную нагрузку. Процессов rphost может быть много по разным машинам внутри корпоративной системы 1C. При этом rphost.exe часто «съедает память» и перегружает процессор. К примеру, это может выглядеть так:

Дано

• сервер 1С: Wndows Server 2016 Standard, 32 Гб ОЗУ, 12-ядерный процессор 2.7 ГГц;
• платформа 1С — 8.3.15.1565 с настройками по умолчанию;
• 60 баз, лицензия платформы ПРОФ.

Проблема

Процессор загружен постоянно на 85-100% (и каждое ядро, и суммарно). Требуется выявить причину такой загрузки и разгрузить процессор.

Решение

Начинаем с самого простого и очевидного. Откроем диспетчер задач Windows, вкладку Details и отсортируем список процессов по колонке CPU.

Если видим один или несколько процессов rphost.exe в топе – значит, процессор загружен 1С. Если процессор загружен, значит какие-то задачи выполняются. А так как процессор загружен слишком часто, то задачи выполняются либо слишком долго, либо слишком быстро и часто.

Но что именно может суммарно выполняться настолько долго в 1С, что это становится проблемой? Находим топ суммарно длительных серверных вызовов. Для этого нам понадобится выполнить сбор технологического журнала (ТЖ). Это специальный механизм платформы 1С 8.3, который позволяет протоколировать все события, происходящие в системе, в том числе системные ошибки.

Настройка его сбора выглядит так:

			<?xml version="1.0"?>
<config xmlns="http://v8.1c.ru/v8/tech-log"> 
  <log location="C:\logs1c" history="2">
  <event>
   <eq property="name" value="CALL"/>
  </event>
  <event>
   <eq property="name" value="SCALL"/>
  </event>
  <property name="all"/>
 </log>
</config>
		

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

			# Топ суммарно длительных вызовов
# Суммарная длительность :: База :: Вызов
y=0;
#grep -P ',CALL,' ./rphost*/*.log | head -n 10000 | awk '{
grep -P ',CALL,' ./rphost*/*.log | awk '{
 posDlit = match($0, "-");
 posCALL = match($0, ",CALL");
 LenDlit = posCALL - posDlit;
 dlit = substr($0, posDlit+1, LenDlit); #длительность вызова (для 8.2 1/10000 секунд, для 8.3 1/1000000 секунд)
 
 ToAdd = 0; # определяет, выполнять ли проверку в массиве и добавление, т.е. пропускать строку или нет
 
 posFunc = match($0, ",Func=");
 if(posFunc!=0) # у регламентных заданий так
 { 
  ToAdd = 1;
  posBase = match($0, "p:processName=");
  LenBase = posFunc - posBase;
  pBase = substr($0, posBase, LenBase);
  gsub("p:processName", "Base", pBase);
  posMemory = match($0, ",Memory=");
  LenMethod = posMemory - posFunc;
  Method = substr($0, posFunc+1, LenMethod);
  KeyStr = pBase " :: " Method; 
 }
 if(posFunc==0) # у пользовательских вызовов так
 {
  posContext = match($0, ",Context=");
  if(posContext!=0)
  {
   ToAdd = 1;
   posBase = match($0, "p:processName=");
   postClientID = match($0, ",t:clientID=");
   LenBase = postClientID - posBase;
   pBase = substr($0, posBase, LenBase);
   gsub("p:processName", "Base", pBase);
   strContexMore = substr($0, posContext+1);
   posEndContext = match(strContexMore, ",");
   Context = substr(strContexMore, 1, posEndContext);
   KeyStr = pBase " :: " Context;
  }
 }
 
 if(ToAdd==1)
 {
  # определяем есть ли уже этот контекст в массиве
  isexist = 0;
   for(i in arr)
   {
    # если есть, то прибавляем только длительность
    if(arr[i]==KeyStr) {brr[i]+=dlit; isexist = 1; break;}
   }
   if (isexist == 0) # если отсутствует, то добавляем новый элемент массива
   {
    y+=1;
    arr[y] = KeyStr;
    brr[y] = dlit;
   }
 } 
} END {
 for (i in arr) {print brr[i] " :: " brr[i]/1000000 " sec :: " (brr[i]/1000000)/60 " min :: " arr[i]}
}' | sort -rnb | head -n 30
		

С помощью GitBash в директории ТЖ запускаем скрипт. Получаем следующий результат:

В топе оказались регламентные задания. Заходим в базы и проверяем периодичность каждого регламентного задания. Периодичность высокая.

Что поможет справиться с загрузкой процессора?

1. Если в работе системы 1С компании есть период нерабочего времени, переносим время запуска на него.

2. В случае, когда нерабочего времени нет (система всегда работает), уточняем, пользуются ли пользователи полнотекстовым поиском. Если нет — отключаем регламентные задания. Если да — уточняем допустимый предел актуальности данных (например, на вчерашний день, двухчасовая актуальность). И меняем периодичность запуска соответственно.

3. Проблему это не решает, если пользователь отвечает, что порога актуальности быть не должно или он должен быть слишком мал, как в примере. Тогда полнотекстовый поиск требуется выполнять только по определённым таблицам, полям. В таком случае для остальных полей требуется отключить свойство использования полнотекстового поиска.

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

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