Обновлено: 04.07.2024

Бывают случаи, когда процесс rphost отъедает много ОЗУ (Иногда даже всю свободную).

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

В результате, даже соседним процессам «Сервера 1С» ее может не хватать, как и всем остальным процессам на данном сервере (особенно если на борту уже есть MS SQL, сервер терминалов, веб сервер и прочие).

К слову, подобные вещи уже давно происходят и с MS SQL, чьи аппетиты не редко приходится усмирять администраторам.

Собственно борьбой с утечками памяти мы и будем заниматься в сегодняшней статье.

Разберем различные способы, которые позволяют решить проблему «утечек» памяти rphost – а.

В 1С признают официально, что утечки памяти есть (на техническом уровне), и проблема не решена. Обещают решить с выходом версии 8.3.20. Также есть надежда, что с выходом 8.3.20 решат и в целом проблему повышено потребления памяти процессами 1С.

На «Сервер 1С» к сожалению, не все так просто как с MS SQL, здесь есть и ограничения версии «ПРОФ», и новые версии платформы. К примеру с 8.3.15 убрали возможность настройки «Допустимый объем памяти», что дополнительно давало нам возможность самим влиять на потребление памяти одного rphost-а. Некоторые настройки перенесли в «Параметры рабочего сервера».

Правда, обещают, что с версии 8.3.20 вернут обратно некоторые настройки регулирования потребления ОЗУ и для версии «ПРОФ», так как на сегодня, это возможно сделать, только используя «КОРП».

В 1С также временами не могут определиться, что оставить в «ПРОФ» а что перенести в «КОРП»:

Что также здорово «запутывает» пользователя.

Но и это еще не все )

Многие эксперты утверждают, что настроек «Сервера 1С» по умолчанию вполне достаточно, и что «Сервер 1С» не надо перезапускать.

Это утверждение только отчасти является верным!

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

А утечки случаются и при небольших нагрузках (на «ПРОФ») и они как минимум могут требовать перезапуска рабочих процессов (rphost) так и более тонких настроек.

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

Перезапуск «Сервера 1С» делаем только когда это действительно необходимо.

(К примеру, разово, в начале расследования утечки памяти).

Далее будет достаточно перезапуска rphost.

В разы же возрастает необходимость внесения правок, если у нас «КОРП»!

Есть высоконагруженные системы, где работают сотни пользователей, тогда действительно требуется чаще вносить изменения в параметры руками на «Сервере 1С», сюда и создание отказоустойчивого кластера, путем добавления «Рабочего сервера», также настройка, направленная на борьбу с утечками памяти (они встречаются и в «КОРП») а их в кластере будет еще больше.

А вот что касается части настроек с целью повысить как то производительность «Сервера 1С» (Не учитывая создания отказоустойчивого кластера серверов 1С), то вот здесь настройки как для «ПРОФ» так и «КОРП» будут малоэффективные.

Что ж, глубину проблемы мы с вами уяснили, теперь начинаем «распутывать».

Сперва разберемся, какое потребление rphost считать за нормальное.

Если говорить прямо, то сегодня на один RPHOST уже уходит больше 4ГБ ОЗУ.

В более старых конфигурациях 1С, эта цифра может быть меньше, а вот в новых (особенно ERP и подобных «тяжелых») , 10 -15 и больше ГБ, уже будет за норму.

ВАЖНО!

Напрасно надеется, что «Серверу 1С» хватит пары Гб, что остались у вас свободны, и тут никакие оптимизации не спасут!

Что в основном влияет на потребление ОЗУ процессом rphost:

1. Количество сеансов
2. Конфигурации 1С
3. КОД (Качество написания)
4. Фоновые задачи (Порожденные регламентными заданиями).
5. Версия платформы 1С

Первое что стоит сделать в борьбе с утечкой:

Останавливаем «Сервер 1С», и очистим кэш на «Сервере 1С»!

И затем после его запуска в «боевых» условиях мы посмотрим на потребление ОЗУ в течение короткого времени от 30 мин до

Бывает, что rphost чрезмерно потребляет ОЗУ не сразу, а на протяжении всего рабочего дня или даже нескольких дней. (Можно увидеть «утечку»).

После чего надо пройтись по сеансам!

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

Память (текущая) в сеансах.

Это объем переданных и полученных данных с момента начала клиентского соединения (в байтах).

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

Затем получив список объектов, мы проводим их диагностику на уровне кода в конфигурации, конечно с привлечением программиста 1С.

Если после анализа, качество кода конфигурации 1С не вызывает у вас сомнения (разобрали что происходит в сеансах пользователей), тогда это и будет «обычное» (или близкое к этому) потребление RPHOST-ов ОЗУ у Вас.

В том случаи, если вместо «приложения» у вас «фоновая задача» кушает много ОЗУ, следует разобрать ее.

Если автор «фонового» известен, тогда поиск проблемы будет сильно упрощен, нам останется только отключить регламентные задачи, которые породили «фоновое задание», что у нас и имеет сильное потребление. (Вкладка Администрирование – Регламентные и фоновые задания).

Если вместо пользователя у вас автор «фоновой задачи» «DefUser» или трудно, поймать, кто запускает «фоновую задачу».

Тогда можно пойти другим путем и в целом на «Сервере 1С» установить «Блокировку регламентных задач» после чего перезапустить «Сервер 1С».

Конечно, совет будет вредным если рег. задания у вас в конфигурации нужны!

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

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

Более правильно, но только для «Аврала» ) будет установка «интервала перезапуска» в свойствах локального кластера:

Установив 86400 секунд, мы автоматизируем процесс перезапуска рабочего процесса раз в сутки (Ночью).

Сделайте настройку так, чтоб не попасть в рабочее время!

Конечно, это не решит проблему «утечки» но с симптомом позволит бороться, это на тот случай если у вас абсолютно нет времени предпринять что-то более изящное.

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

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

У кластера серверов 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 секунд.

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

У многих возникают проблемы с rphost.exe, разного вида:

• rphost занимает всю память
• rphost грузит процессор
• rphost жрет память

причем 1С даже на запущена, а в диспетчере следующее:

ежеминутно расчет на 2-3 мегабайта.

Как быть и что делать?

Решение проблем с rphost

То что 1С у пользователей не запущено - не значит что сервер 1С не должен работать

Он работает- выполняя фоновые задания:

Есть несколько вариантов решения:

1. Обновить платформу 1С и поддерживайте ее в актуальном состоянии

2. Перезапустить сервер или службу Агент 1С Предприятия, но это временное лечение.

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

Отключить можно в свойствах базы

Установите галку Блокировка регламентных заданий включена и нажмите ОК

Для типовых конфигураций советую отключить обновление Полнотекстового поиска:

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

На этом тестовом сервере пока всего 2GB памяти, поэтому когда rphost съедает память на 600 - 850 мегабайт, свободной память остается только 6% - сервер тормозит нереально

Установим следующие параметры для рабочих процессов:

Основное: 500 мб - допустимый объем памяти и Режим распределения нагрузки - Приоритет по памяти

Подробнее об этом я уже писал в статье Оптимальные параметры кластера 1С 8.3

После установки таких настроек кластера, сервер начал стабильно работать.

Интересно услышать Ваши комментарии - Какой у Вас сервер и какие настройки делаете Вы для оптимизации

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

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

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

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

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

    
  • Не допускается очистка диска содержащего текущий загрузочный или системный тома
    
  • Разгон видеокарты gtx 670
    
  • Nibitor не видит видеокарту
    
  • Какой процессор нужен для gt 1030
    
  • Процессор в программировании это