Обновлено: 04.07.2024

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

Второй и вполне логичный шаг - автоматический перезапуск процессов на сервере, о чем, собственно, и хочется написать.

Поскольку служба агента сервера 1С Предприятия представляет собой стандартную службу, в арсенале Windows есть стандартный способ остановки и запуска служб из командной строки командами net stop и net start. Достаточно эти команды лишь включить в bat-файл и настроить шедулер на запуск bat-файла по расписанию, я настроил перезапуск один раз в сутки, в ночное время. Следует иметь ввиду, что если перезапускать рабочие процессы в рабочее время, все подключенные к серверу 1С Предприятия клиенты будут отключены!
Кроме того, чтобы немного разнести по времени команды остановки и запуска службы, будем использовать известную утилиту sleep.exe, которую легко найти в Сети.

Примерный текст bat-файла restart1c.bat:

rem @echo off
rem \\----- начало скрипт остановки и запуска агента сервера 1С Предприятия----\\
set logfile="stopstartlog.txt"
set timeout=20
echo %date% %time% >>%logfile%
net stop "1C:Enterprise 8.1 Server Agent" >>%logfile%
c:\scripts\sleep %timeout%
echo %date% %time% >>%logfile%
net start "1C:Enterprise 8.1 Server Agent" >>%logfile%
c:\scripts\sleep %timeout%
rem \\----- конец скрипт остановки и запуска агента сервера 1С Предприятия----\\

Объяснение используемых переменных и команд:
* logfile - файл stopstartlog.txt, куда будут записываться результаты выполнения команд, размещается в том же каталоге, что и сам bat-файл;
** timeout - время в секундах;
*** c:\scripts - каталог, где предполагается разместить программу sleep.exe, bat-файл и лог-файл;

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

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

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

Соединения кластера

Утилита администрирования кластера серверов позволяет посмотреть список соединений:

• кластера в целом (ветка "Центральные серверы 1С:Предприятия 8.1/ <имя сервера>/ Кластеры/ <номер порта кластера>/ Соединения");
• рабочего процесса (ветка "Центральные серверы 1С:Предприятия 8.1/ <имя сервера>/ Кластеры/ <номер порта кластера>/ Процессы/ <имя рабочего процесса>/ Соединения" или ветка "Центральные серверы 1С:Предприятия 8.1/ <имя сервера>/ Кластеры/ <номер порта кластера>/ Рабочие серверы/ <имя рабочего сервера>/ Процессы/ <имя рабочего процесса>/ Соединения");
• информационной базы (ветка "Центральные серверы 1С:Предприятия 8.1/ <имя сервера>/ Кластеры/ Информационные базы/ <имя информационной базы>/ Соединения").

Среди соединений имеются:

• пользовательские соединения (1С:Предприятие, Конфигуратор, COM-соединения, WS-соединение, Фоновое задание, Консоль кластера, COM-администратор)
• служебные соединения (Планировщик заданий, Отладчик)

Пользовательские соединения относятся к информационной базе и видны в списке соединений:

• своей информационной базы;
• своего рабочего процесса;
• кластера в целом.

Служебные соединения не относятся к конкретной информационной базе и видны в списках соединений:

• своего рабочего процесса;
• кластера в целом.

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

Разрыв соединения

• если по инициативе пользовательского соединения на сервере не выполняется никакого действия, то соединение может быть разорвано всегда;
• если в момент разрыва соединения соединение выполняет на сервере код на встроенном языке, то разрыв соединения возможен при переходе выполнения от одной строки кода на встроенном языке к другой;
• если соединение выполняет запрос к базе данных, то для MS SQL Server и IBM DB2 1С:Предприятие предпринимает попытку прервать выполнение запроса сервером баз данных. Соединение будет разорвано, если пользователь базы данных, от имени которого сервер 1С:Предприятия выполняет обращение к базе данных, имеет соответствующие права, и СУБД готово выполнить функцию прекращения исполнения запроса;
• в других случаях попытка принудительного разрыва пользовательского соединения может не привести к фактическому разрыву соединения.

Принудительный разрыв служебных соединений невозможен.

Выключение и остановка рабочего процесса

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

После выключения запущенного рабочего процесса он останавливается не сразу, а только тогда, когда с ним не будет установлено ни одного пользовательского соединения. При этом новых пользовательских соединений с данным рабочим процессом устанавливаться не будет. Для обеспечения возможности остановки рабочего процесса даже в том случае, когда с ним еще установлены пользовательские соединения, в Утилите администрирования кластера серверов предусмотрен параметр "Выключенные процессы останавливать через. " в свойствах кластера, а в средствах программного администрирования кластера - свойство ExpirationTimeout объекта "Кластер серверов" (IClusterInfo).

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

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

Регламентный перезапуск рабочих процессов

Для минимизации отрицательных последствий фрагментации и утечки памяти в рабочих процессах может быть предусмотрен их автоматический перезапуск. В 1С:Предприятие встроена возможность автоматического перезапуска рабочих процессов через заданные интервалы времени. Для этого в Утилите администрирования кластера серверов предназначен параметр "Рабочие процессы перезапускать через. " в свойствах кластера, а в средствах программного администрирования кластера - свойство LifeTimeLimit объекта "Кластер серверов" (IClusterInfo). Если этот параметр отличен от 0, то для каждого рабочего процесса через заданное количество секунд после его запуска:

• создается и запускается новый процесс;
• текущий процесс выключается.

Это позволяет обеспечить автоматическое ограничение времени жизни рабочих процессов. Рекомендуется время, заданное параметрами LifeTimeLimit и ExpirationTimeout, связывать с длительностью технологического цикла конкретной информационной базы (сутки, неделя и т. д.).

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

Приведенный ниже пример кода позволяет установить время принудительной остановки рабочих процессов:

Следующий фрагмент кода является простым примером регламентного перезапуска рабочих процессов:

Значительное потребление памяти процессами кластера на сервере приложений

У кластера серверов 1С Предприятия есть несколько настроек перезапуска процессов по превышению порога памяти. Их можно найти в параметрах кластера в консоли администрирования(рис. 1).

Рис. 1. Параметры кластера.

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

Рекомендуется всегда настраивать параметры

• Допустимый объем памяти
• Интервал превышения допустимого объема памяти
• Выключенные процессы останавливать через

"Допустимый объем памяти" стоит устанавливать из расчета, того, что в случае срабатывания условия превышения показателя будет запущен ещё один процесс rphost того же объема, как при нормальной работе кластера серверов в этой информационной системе.

Например, на рабочем сервере имеем 12 Гб ОЗУ. Допустим для конкретной информационной системы характерен размер rphost около 3 Гб. В этом случае порог превышения памяти следует рассчитывать следующим образом:

"Допустимый объем памяти" = 12 ГБ - 2 Гб (объем, занимаемый процессами системы) - 3 Гб * 1 rphost (объем всех процессов rphost) = 7 Гб. Т.е. процесс rphost в худшем сценарии может вырасти до 7 Гб.

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

"Допустимый объем памяти" = 12 ГБ - 2 Гб (объем, занимаемый процессами системы) - 3 Гб * 2 rphost (объем всех процессов rphost) = 4 Гб. Т.е. процесс rphost в худшем сценарии может вырасти до 4 Гб.

Такая рекомендация исходит из особенностей поведения в момент перезапуска процессов кластера. Как это происходит:

• процесс rphost превышает "Допустимый объем памяти" в течение "Интервал превышения допустимого объема памяти" секунд, срабатывает условие перезапуска процессов кластера.
• запускается "новый" процесс rphost
• "старый" процесс rphost выключается, но не завершается
• соединения назначаются на "новый" процесс rphost, который сразу полноценно включается в работу
• "старый" процесс будет исполнять вызовы (которые ещё существуют) максимум в течение ещё "Выключенные процессы останавливать через" секунд, но не более того.
• через время "Выключенные процессы останавливать через" "старый" процесс rphost завершается.
• новый процесс полноценно работает

Т.е. в течение периода, указанного в "Выключенные процессы останавливать через" будет одновременно работать как минимум два процесса rphost: "старый" и "новый".

Не следует указывать "Допустимый объем памяти" меньше нормального рабочего объема памяти процесса rphost для вашей системы, т.к. противном случае у вас постоянно будут перезапускаться процессы кластера серверов.

• Интервал превышения допустимого объема памяти
• Выключенные процессы останавливать через

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

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

Замедление работы «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 появилась возможность использовать параметр не только в КОРП, но и в версии ПРОФ. Однако, попытки использовать его не привели к желаемому результату. Поскольку параметр ограничивает общий объем памяти всех рабочих процессов.

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

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

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

  Читайте также:

    
  • Списание задолженности в 1с erp где найти
    
  • Как сделать гравировку в фотошопе
    
  • Как получить дискорд нитро в эпик геймс без банковской карты
    
  • Rubetek программа для компьютера
    
  • Как убрать отбор в отчете 1с