Замедление работы «1С:Управление торговлей» через 6 часов после запуска сервера «1С»
Большое предприятие ведет свою деятельность в клиент-серверной базе основанной на «1С:Управление торговлей» ред.11.2. При длительной работе более 6 часов с момента запуска сервера от пользователей стали поступать жалобы об общем замедлении работы системы. При этом замедление наблюдалось буквально во всем: открытие форм объектов, формирование отчетов, проведение документов и так далее.
В рамках статьи рассмотрены причины такого поведения системы, возможные варианты настройки сервера типовыми средствами «1С», а также представлен авторский альтернативный подход к решению проблемы.
Оглавление
Необходимые сведения об устройстве сервера «1С»
На рисунке представлены элементы, которые задействованы в работе кластера серверов, а именно:
- процессы кластера серверов:
- ragent.exe,
- rmngr.exe,
- rphost.exe.
- хранилища данных:
- список кластеров,
- реестр кластера.
Функционирование компьютера в составе кластера обеспечивается процессом ragent.exe, который называется агентом сервера. Соответственно компьютер, на котором запущен агент сервера, называется рабочим сервером. Одной из функций агента сервера является ведение списка кластеров, расположенных на данном рабочем сервере.
Непосредственно кластер серверов включает в себя следующие элементы:
- один или несколько процессов rmngr.exe;
- реестр кластера;
- один или несколько процессов rphost.exe.
Процесс rmngr.exe называется менеджером кластера. Этот процесс управляет функционированием всего кластера.
Процесс rphost.exe называется рабочим процессом. Рабочий процесс обслуживает непосредственно клиентские приложения, взаимодействует с сервером баз данных и в нем, в частности, могут исполняться процедуры серверных модулей конфигурации.
В процессе своей работы рабочий процесс со временем потребляет все больше памяти, что в конечном счете приводит к падению производительности сервера. Таким образом, объем памяти занимаемый рабочим процессом в некоторой степени коррелирует со степенью его деградации.
Параметры стенда
Будет рассматриваться поведение платформы на примере доработанной конфигурации основанной на «1С:Управление торговлей» ред. 11.2.
- Сервер 1С под Windows.
- Одновременно работающих пользователей около 800.
- ОЗУ 192Гб. Абсолютное значение памяти не так существенно. Важно, что через какое-то время рабочие процессы замедляются (деградируют) даже при видимом свободном объеме памяти.
- Остальные параметры также не существенны.
Расследование
Повышенный расход памяти и возможные причины
Повышенное потребление памяти происходит по разными причинам, например, избыточное кэширование данных платформой «1С» или наличие недочетов в самом прикладном решении. Как примеры таких недочетов можно назвать наличие циклических ссылок объектов друг на друга, наличие избыточных сеансовых данных.
Расследование и исправление таких недочетов в прикладном решении является трудоемкой задачей, которую сложно выполнить в короткие сроки. Поэтому эксплуатацию прикладного решения приходится производить в сложившихся условиях.
Штатные возможности по оптимизации платформы «1С:Предприятие»
Для отказоустойчивой и производительной работы кластер серверов «1С:Предприятие» предусматривает возможность перезапуска рабочих процессов. Однако, настройки условий перезапуска рабочих процессов могут быть сильно ограничены в разных версиях платформы.
Например, в версии ПРОФ платформы 8.3.15 можно настроить перезапуск рабочих процессов либо по времени, например, каждый час, либо при превышении объема памяти всех рабочих процессов заданного лимита, что не всегда является оптимальным.
Поиск решения
В сервере «1С:Предприятие» есть некий пул соединений, которые могут использоваться разными сеансами по мере необходимости. В то время как сеанс бездействует у него нет соединения. Лишние соединения закрываются не сразу, а примерно через 15–20 минут.
При перезапуске рабочего процесса все сеансы находящиеся на нем необходимо переместить на другой рабочий процесс, при этом в процессе переноса открывается соединение. Именно поэтому перезапуск рабочих процессов наглядно видно на графике количества соединений.
Поскольку пользователи заходят в прикладное решение в основном в одно и то же время, то и процессы оказываются запущены практически одновременно и поэтому их перезапуск происходит практически одновременно (при настройке перезапуска каждый час).
Удобно видеть перезапуск, отслеживая загрузку процессора, а также количество соединений.
На графике ниже показана загрузка ЦП сервера за тот же период. Перезапуск даже одного рабочего процесса это весьма трудозатратная операция для сервера, а если происходит одновременный перезапуск всех рабочих процессов, то это приводит к повышенной нагрузке на сервер.
В рассматриваемом прикладном решении процесс перезапуска всех рабочих процессов мог длиться до 20 минут, при этом средняя загрузка ЦП поднималась выше 60%. Длительность операции перезапуска рабочего процесса зависит от количества сеансов и размера сеансовых данных в каждом из них, а также от степени деградации процесса, чем дольше он не перезапускался, тем дольше будет длиться его перезапуск. Из-за этого несколько раз в день отзывчивость сервера значительно падала, что сопровождалось жалобами пользователей.
После перехода прикладного решения на 8.3.15.1830 появилась возможность использовать параметр
«ВременноДопустимыйОбъемПамятиПроцессов»не только в КОРП, но и в версии ПРОФ. Однако, попытки использовать его не привели к желаемому результату. Поскольку параметр ограничивает общий объем памяти всех рабочих процессов.
Если задать его слишком маленьким, то перезапуск рабочих процессов будет слишком частым и сервер будет вести себя также, как и при перезапуске по времени. Если задать его побольше, то перезапуск рабочих процессов не будет производиться до тех пор, пока в сумме все они не превысят лимит, а в это время будет происходить их деградация и снижение производительности.
Когда же лимит будет превышен начнется перезапуск рабочих процессов, но процесс будет слишком частый, как и в предыдущем случае.
Очевидно, для того чтобы реализовать регулярный, но не слишком частый перезапуск деградировавших рабочих процессов параметр
«ВременноДопустимыйОбъемПамятиПроцессов»необходимо постоянно изменять в зависимости от количества сеансов или количества активных рабочих процессов. Но как вычислить эту зависимость не совсем ясно.
Решение
Скрипт перезапуска рабочих процессов
$WorkBaseServer = "ServerName:1540"
$IBNameWorkBase = "BaseName"
$Connector = new-object -comobject "V83.COMConnector"
$AgentConnection = $Connector.ConnectAgent($WorkBaseServer)
$Clusters = $AgentConnection.GetClusters()
$Cluster = $Clusters.GetValue(0)
$AgentConnection.Authenticate($Cluster,"Login","Password")
$WorkingProcesses = $AgentConnection.GetWorkingProcesses($Cluster)
$WorkingServers = $AgentConnection.GetWorkingServers($Cluster)
$mem = 0
ForEach ($wp In $WorkingProcesses)
{
if ($wp.IsEnable)
{
$mem = $mem + $wp.MemorySize
}
}
$mem = $mem*1024
$mem = $mem - 1024*1024*512
if ($mem -gt 1024*1024*1024*4)
{
$WorkingServers[0].TemporaryAllowedProcessesTotalMemory = $mem
$AgentConnection.UpdateWorkingServer($Cluster,$WorkingServers[0])
Start-Sleep -s 5
$WorkingServers[0].TemporaryAllowedProcessesTotalMemory = 0
$AgentConnection.UpdateWorkingServer($Cluster,$WorkingServers[0])
}
Для решения проблемы был написан скрипт. Логика работы скрипта следующая: раз в 10 минут производится суммирование объема памяти всех активных рабочих процессов, устанавливается параметр
«ВременноДопустимыйОбъемПамятиПроцессов»в значение равное полученной сумме за вычетом 512Мб, чтобы получить гарантированное превышение по памяти.
Далее скрипт ожидает, пока один из рабочих процессов перейдет в выключенное состояние, и устанавливает параметр
«ВременноДопустимыйОбъемПамятиПроцессов»в ноль.
Таким образом, достигается постепенный равномерный перезапуск рабочих процессов. Причем перезапуск рабочих процессов делается строго по одному и перезапускается рабочий процесс занимающий самый большой объем памяти. Жалобы пользователей прекратились.
Еще статьи по теме оптимизации производительности «1С»:
- База «1С» растёт и всё тормозит. Что делать?
- Ускоряем в 3 раза открытие сложной формы в 1С 8.3
- Страничные блокировки в MS SQL Server при проведении документа в документе в 1С
Чтобы не пропустить новые статьи из цикла «От экспертов 1С-Рарус» подпишитесь на рассылку «Новости компании 1С‑Рарус». Рассылка будет приходить 1 раз в две недели и содержать ссылки на все новые статьи, опубликованные на rarus.ru.
От экспертов «1С-Рарус»
