Повышение стабильности работы сервера 1С через оптимизацию запуска рабочих процессов в ПРОФ и КОРП версиях 1С:Предприятия

Автор

Производительность высоконагруженных систем 1С
Особенности лицензий «1С:Предприятие КОРП»
Необходимые сведения об устройстве сервера 1С
Влияние количества рабочих процессов на производительность и потребление памяти сервера 1С
Деградация рабочих процессов
Способы решения проблемы деградации рабочих процессов
Вместо заключения

Производительность высоконагруженных систем 1С

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

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

В статье рассмотрены нестандартные подходы к настройке и обслуживанию сервера кластера 1С. Такие подходы могут дать ощутимый результат при эксплуатации высоконагруженного сервера 1С. Под высоконагруженными серверами будем полагать более 300–400 одновременных активных сеансов, независимо от используемой лицензии — КОРП или обычная лицензия.

Особенности лицензий «1С:Предприятие КОРП»

Лицензия КОРП предоставляет дополнительные возможности по настройкам, которые позволяют повысить стабильность работы кластера. В качестве примера можно отметить следующие возможности:

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

При этом версия КОРП, так же как и обычная лицензия, имеет ограниченное количество сценариев для перезапуска рабочих процессов (РП):

Регулярный перезапуск РП через заданный интервал времени.
Перезапуск РП превысивших временно допустимый объем памяти рабочих процессов.

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

Стоит принимать во внимание тот факт, что лицензия КОРП стоит существенно больше обычной лицензии.

Необходимые сведения об устройстве сервера 1С

На рисунке представлены элементы, которые задействованы в работе кластера серверов, а именно:

Процессы кластера серверов:
- ragent.exe;
- rmngr.exe;
- rphost.exe.
Хранилища данных:
- список кластеров;
- реестр кластера.

Функционирование компьютера в составе кластера обеспечивается процессом ragent.exe, который называется агентом сервера. Компьютер, на котором запущен агент сервера, называется рабочим сервером. Одной из функций агента сервера является ведение списка кластеров, расположенных на данном рабочем сервере.

Непосредственно кластер серверов включает в себя следующие элементы:

один или несколько процессов rmngr.exe;
реестр кластера;
один или несколько процессов rphost.exe.

Процесс rmngr.exe называется менеджером кластера. Этот процесс управляет функционированием сервера в кластере.

Процесс rphost.exe называется рабочим процессом. Рабочий процесс обслуживает непосредственно клиентские приложения, взаимодействует с сервером баз данных и в нем, в частности, могут исполняться процедуры серверных модулей конфигурации.

Влияние количества рабочих процессов на производительность и потребление памяти сервера 1С

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

При настройке кластера эксперт оперирует следующими параметрами:

количество рабочих процессов;
количество соединений на процесс;
объем памяти на процесс;
интервал перезапуска рабочих процессов.

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

Установить непосредственно можно только «Количество соединений на процесс» и «Интервал перезапуска РП». Остальные параметры можно регулировать только опосредованно.

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

Универсальной рекомендации по настройке этих параметров не существует, поскольку они очень сильно зависят от конкретной конфигурации информационной базы, активности сеансов и объема оперативной памяти доступной кластеру. Есть так называемые «параметры по умолчанию», которые устанавливаются при создании нового кластера.

Параметр «Количество соединений на процесс»

В современных версиях «1С:Предприятие» устанавливается количество соединений на процесс 256, хотя в более ранних релизах этот параметр был равен 128.

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

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

Таблица: Сравнительный анализ по изменению количества рабочих процессов

Таким образом, универсального решения здесь нет и нужно искать некий баланс между этими двумя крайностями.

Из нашего опыта и опыта коллег, участвовавших в крупных внедрениях (более тысячи пользователей), на текущий момент времени мы пришли к заключению, что баланс обычно находится в районе 7–15 рабочих процессов.

Из интересных особенностей управления параметром «Временно допустимый объем памяти процессов» можно отметить тот факт, что в документации ИТС указана возможность использования данного параметра только для лицензии КОРП. При этом установка параметра все же работает (он не игнорируется) с обычной лицензией в версиях платформы 8.3.15 (начиная с 8.3.15.1700), 8.3.17, 8.3.18. А, например, в версиях 8.3.16 он игнорируется.

Параметр «Интервал перезапуска РП»

Интервал перезапуска РП по умолчанию не установлен. Применительно к высоконагруженным системам это со временем ухудшает параметры быстродействия сервера. Можно было бы рекомендовать перезапускать РП каждые несколько часов. Но и здесь все не так очевидно, как кажется на первый взгляд.

Поскольку пользователи заходят в прикладное решение в основном в одно и то же время, то и процессы оказываются запущены практически одновременно и поэтому их перезапуск происходит практически одновременно. Такое поведение системы приводит к повышенному времени отклика сервера во время таких массовых перезапусков РП. А у конечных пользователей это выглядит как «подвисание» клиентского приложения на десятки секунд.

Параметр «Принудительно завершать проблемные процессы»

Еще один интересный и неоднозначный параметр — это «Принудительно завершать проблемные процессы». Здесь под процессами подразумеваются не только рабочие процессы, но и другие компоненты кластера. При его включении система анализирует такие показатели, как:

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

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

Деградация рабочих процессов

В процессе своей работы рабочий процесс (РП) со временем потребляет все больше памяти, что в конечном счете приводит к увеличению времени отклика рабочих процессов и падению производительности сервера в целом.

В сообществе специалистов 1С такое явление назвали «деградацией рабочих процессов». Гипотетически деградация РП может происходить по разным причинам:

фрагментация памяти рабочего процесса;
избыточное кэширование объектных данных платформой 1С;
наличие циклических ссылок объектов друг на друга;
наличие избыточных сеансовых данных.

Степень деградации РП мы не можем измерить никаким объективным критерием или метрикой. Однако, известно, что степень деградации РП в некоторой степени коррелирует с:

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

Таким образом, эти показатели можно считать лишь косвенным показателем степени деградации рабочего процесса.

Деградация рабочих процессов

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

Способы решения проблемы деградации рабочих процессов

Увеличение количества рабочих процессов

При каком-то определенном сценарии работы пользователей кластер обслуживает некое среднее количество вызовов. Эти вызовы делятся между рабочими процессами. Таким образом, увеличение количества рабочих процессов может замедлить скорость деградации каждого отдельно взятого РП, поскольку каждый из них будет обслуживать меньше вызовов. Увеличение количества РП необходимо делать в разумных пределах и с четким пониманием возможных негативных последствий, описанных выше.

Разделение нагрузки на несколько рабочих серверов

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

Своевременный перезапуск РП

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

Регулярный перезапуск РП через заданный интервал времени.
Настройка этого параметра часто приводит к массовому перезапуску рабочих процессов запущенных одновременно. Что не всегда хорошо сказывается на времени реакции сервера в момент такого перезапуска.
Перезапуск РП превысивших временно допустимый объем памяти рабочих процессов.
По умолчанию данный параметр установлен в «0». Это значит, что перезапуск РП будет осуществляться при превышении 80% памяти доступной кластеру. Поскольку рост потребления памяти происходит неравномерно между рабочими процессами и лишь косвенно указывает на степень деградации, то настроить своевременный перезапуск РП с помощью статичного указания временно допустимого объема памяти достаточно сложно.

Своевременный перезапуск РП

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

	Сценарий 1	Сценарий 2
Лимит 1	Есть явно деградировавший РП, но перезапуск его не происходит.	Деградировали уже все РП, но перезапустится только один. А хотелось бы не доводить ситуацию до такого состояния и перезапускать заранее.
Лимит 2	Есть явно деградировавший РП, есть его перезапуск.	Слишком низкий лимит приводит к частому аварийному перезапуску множества РП сразу.

Мы реализовали свой способ перезапуска РП, который делает своевременный перезапуск деградировавших РП. Он основан на регулярном перезапуске РП через заданный интервал времени, но не приводит к массовому перезапуску рабочих процессов, запущенных одновременно, поскольку перезапускает лишь один РП в единицу времени (например, раз в 10–20 минут).

Логика работы скрипта

Раз в 10 минут производится суммирование объема памяти всех рабочих процессов, устанавливается параметр «временно допустимый объем памяти рабочих процессов» в значение равное полученной сумме за вычетом 512Мб, чтобы получить гарантированное превышение по памяти.

Далее скрипт ожидает, пока один из рабочих процессов перейдет в выключенное состояние, и устанавливает параметр «временно допустимый объем памяти рабочих процессов» в ноль. Опционально, можно пропускать перезапуск РП если в текущий момент явно нет ни одного деградировавшего РП — память самого крупного РП не превышает некоего заведомо низкого значения, при котором перезапуск точно не нужен, например, 8ГБ.

За счет этого достигается равномерный перезапуск рабочих процессов. Причем перезапуск рабочих процессов делается строго по одному и перезапускается рабочий процесс, занимающий самый большой объем памяти.

В качестве дополнительного бонуса к статье мы приводим примеры скриптов перезапуска рабочих процессов в двух вариантах: для Windows на PowerShell с использованием COM-объектов и для Linux на скрипте Bash с использованием RAC.

Хотелось бы обратить внимание на то, что эти скрипты не претендуют на какую бы то ни было эталонность, а просто являются демонстрацией того, как можно программно управлять рассмотренными в статье настройками кластера. Для этого можно использовать RAC или COM-объекты и по вкусу завернуть все это в программу на любом понравившемся языке. Подробнее о настройке и запуске 1С под Linux читайте тут.

DeleteWorkingProcess
ByMemory.sh

Скрипт для bash (в качестве параметра принимает номер порта кластера):

#!/bin/bash
logfile="/home/example/DeleteWorkflowByMemory_log.txt"

  echo $(date)  start script on port $1 >> $logfile

  _path="/opt/1C/v8.3/8.3.17-1549"

  host=localhost:$1 
_cluster=$($_path/rac  cluster list $host| grep 'cluster'| awk -F' ' '{print $3}')

  _server=$($_path/rac  server --cluster=$_cluster list $host| grep 'server '| awk -F' ' '{print $3}')

  

  result=$($_path/rac  process --cluster=$_cluster list $host| awk -F' ' '{

  if(match($1,  "is-enable")&&match($3, "yes"))

  k=1; 

  else if(match($1,  "is-enable")&&match($3, "no"))

  k=0; 

  

  else if(match($1,  "pid"))

  pid=$3; 

  else if(match($1,  "memory-size"))

  {

  sum += $3;  

  mem = k*$3;

  arr_mem[pid] = mem

  #print "mem="mem;   

  }

  }

  END {max = 0;

  for (i in  arr_mem) {

  if(arr_mem[i]>max) 

  max = arr_mem[i]

  }

  print  "sum=" sum "; max=" max "; id=" i}')
sum_mem=$(echo  $result | awk -F';' '{print $1}'| awk -F'=' '{print $2}' ) #total memory in  kilobytes 

  max_mem=$(echo  $result | awk -F';' '{print $2}'| awk -F'=' '{print $2}' ) #max memory in  kilobytes 

  id=$(echo $result  | awk -F';' '{print $3}'| awk -F'=' '{print $2}' ) #max memory in kilobytes 
sum_mem=$((1024*$sum_mem))  #in bytes 

  max_mem=$((1024*$max_mem))  #in bytes 
mem_limit=$((8*1024*1024*1024))  #8GB - single process memory threshold  

  sum_mem_limit=$(($sum_mem-1024*1024*512))  #sum_mem-512MB = temporary memory limit of all processes 

  default_mem=0
if [[ $max_mem  -gt $mem_limit ]]; then 

  $_path/rac server  --cluster=$_cluster $host update --server=$_server   --temporary-allowed-total-memory=$sum_mem_limit

  echo set mem = $sum_mem_limit  >> $logfile

  echo waiting 20 sec...  >> $logfile

  sleep 20

  $_path/rac server  --cluster=$_cluster $host update --server=$_server  --temporary-allowed-total-memory=$default_mem

  echo set mem = $default_mem >>  $logfile

  fi

  echo "finish"

УдалитьРППоПамяти.ps1

Скрипт для PowerShell:

$WorkBaseServer = "srv-1c:1540"
$Connector =  new-object -comobject "V83.COMConnector" 

  $AgentConnection  = $Connector.ConnectAgent($WorkBaseServer) 

  $Clusters =  $AgentConnection.GetClusters() 

  $Cluster = $Clusters.GetValue(0) 

  $AgentConnection.Authenticate($Cluster,"","") 
$WorkingProcesses  = $AgentConnection.GetWorkingProcesses($Cluster)

  $WorkingServers =  $AgentConnection.GetWorkingServers($Cluster)

  $mem = 0

  $mem_max = 0

  ForEach ($wp In  $WorkingProcesses)

  {

  $mem  = $mem + $wp.MemorySize

  if ($wp.IsEnable)

  {

  if ($wp.MemorySize -gt  $mem_max) {$mem_max = $wp.MemorySize}

  }

  }
$mem = $mem*1024

  $mem = $mem -  1024*1024*512

  $mem_max =  $mem_max*1024

  if ($mem_max -gt  1024*1024*1024*8)

  {

  $WorkingServers[0].TemporaryAllowedProcessesTotalMemory  = $mem

  $AgentConnection.UpdateWorkingServer($Cluster,$WorkingServers[0])

  Start-Sleep -s 5

  $WorkingServers[0].TemporaryAllowedProcessesTotalMemory  = 0

  $AgentConnection.UpdateWorkingServer($Cluster,$WorkingServers[0])

  }

Вместо заключения

Почему раздел называется не «Заключение», а «Вместо заключения»? Причина кроется в том, что статья посвящена не тому, чтобы дать набор готовых инструкций, рекомендаций, рецептов, а настроить эксперта-читателя на тон размыслительный.

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

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