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

Содержание

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

  • Переходим на страницу Сеансы
  • Находим колонку Память (текущая)
  • Упорядочиваем по колонке
  • Записываем номера сеансов, которые использовали больше всего памяти
  • Завершаем сеансы
  • Проверяем, успело ли сработать условие перезапуска процессов кластера серверов
  • Если есть сеансы, которые находятся в длительном клиент-серверном вызове, то записываем номера сеансов
  • Завершаем сеансы, убеждаемся, что процессы успешно перезапустились.
  • Убеждаемся, что памяти достаточно
  • Полученные дампы и технологические журналы (если собирались) отправляем в 1С с подробным описанием проблемы и симптомов
  • Следует учитывать, что нет смысла отправлять дампы в 1С, если на сервере действительно очень мало доступной оперативной памяти, а rmngr при нормальной работе занимает ровно тот же самый объем

У кластера серверов 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 для вашей системы, т.к. противном случае у вас постоянно будут перезапускаться процессы кластера серверов.

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

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

Нужно запустить batch file из директории, в которой расположен ProcDump (http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx)

echo Start dumping all rmngrs, rphosts, and ragents on this server.

Анализ причин роста сеансовых данных

Сеансовые данные

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

При вызове методов: ПоместитьВоВременноеХранилище, ПоместитьФайл, НачатьПомещениеФайла, значения указанные в параметрах, записываются в сеансовые данные.

При фоновом исполнении отчетов СКД, результат отчета помещается в сеансовые данные, а затем передается в клиентскую часть.

С точки зрения операционной системы, сеансовые данные представляют собой файлы в каталоге …srvinforeg_ snccntx .

С точки зрения внутренней структуры — это noSQL база данных (key-value storage).

Особенности работы платформы с сеансовыми данными

За работу с сеансовыми данными отвечает менеджер кластера – rmngr.exe Если в кластере несколько рабочих серверов, то сеансовые данные будут расположены в соответствии с требованиями назначения функциональности.

Если требования не заданы, то сеансовые данные распределятся равномерно по всем рабочим серверам.

Сеансовые данные растут блоками по 64 Мб. Когда заканчивается блок, то менеджер кластера выделяет следующий блок в 64Мб.Блоки большего объема возможны в результате помещения объемных данных во временные хранилища.

Для обеспечения скорости работы, платформа всегда пишет новые данные в конец, аналогично transaction log в СУБД. Таким образом, размер сеансовых данных постоянно растет. Во всем объеме сеансовых данных, существуют как актуальные, так и устаревшие данные. Актуальность данных определяется способом их помещения:

Перед выделением следующего блока на диске, проверяется, прошло ли 5 секунд с момента выделения предыдущего блока. Если 5 секунд прошло, то запускается сборщик мусора (key value garbage collector). Сборщик оценивает процент актуальных сеансовых данных в общем объеме. Если актуальные данные занимают менее 25% от общего объема, то все актуальные данные копируются в новые файлы, а затем все старые файлы сеансовых данных удаляются.

Так как каждый сеанс (клиенты, фоновые задания, web-сервисы) в своей работе постоянно пишет информацию в сеансовые данные, то при большом количестве пользователей, скорость дисковой подсистемы, на которой расположены файлы сеансовых данных, играет очень важную роль. При большом количестве пользователей, рекомендуется располагать файлы сеансовых данных на максимально быстрых дисках. Желательно RAM-drive. Отказоустойчивость дисков не важна, т.к. при потере сеансовых данных, никакой важной информации утеряно не будет.

Следует отметить порядок размещения сеансовых данных. Если поместить во временное хранилище двоичные данные или файл, то эти данные пройдут в качестве потока байт через rphost, затем в rmngr, который сбросит этот поток на диск. Если же, в качестве помещаемого значения, будет выступать коллекция (таблица значений, результат запроса, массив…), то сначала вся эта коллекция разместиться в памяти rphost, а только затем преобразуется в поток байт и будет передана в rmngr.

Размещение сеансовых данных в памяти

При работе кластера 1С:Предприятия, файлы сеансовых данных отображаются в память (mapping). Подробнее см. статью.

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

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

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

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

Следует учитывать данную особенность счетчика MemoryAvailable Mbytes при построении систем мониторинга или приложений, которые опираются на объем доступной оперативной памяти.

Для косвенной оценки эффективности работы операционной системы с сеансовыми данными, можно использовать счетчик MemoryPage Faults/sec, который показывает на сколько часто процессы обращаются за страницами в память, но не находят их там и подгружают с диска.

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

Проблемы сеансовых данных

Ошибка совместного доступа к файлу snccntx.dat

При появлении данной ошибки необходимо действовать по алгоритму:

1. Проверить права на папку сеансовых данных для пользователя, от которого запущена служба сервера 1С:Предприятия. Должны быть полные права.

2. Открыть на рабочем сервере диспетчер задач, установить видимость колонки Командная строка

3. Необходимо найти процессы rmngr.exe с одинаковым значением параметра –pid.

4. Открыть консоль кластера. Развернуть ветку кластера, порт которого соответствует параметру –regport , найденных rmngr.exe с одинаковым значением параметра –pid

5. Сопоставить PID из диспетчера задач с PID в консоли кластера. Тот процесс rmngr.exe, которого нет в консоли – принудительно завершить.

Закончилось место на диске, где расположены сеансовые данные

Необходимо следить за наличием свободного места на диске, где расположены сеансовые данные.

Не следует размещать файлы технологических журналов на одном диске с сеансовыми данными.

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

Так же, необходимо следить за размером самих сеансовых данных. Если периодически их размер становится существенным, то необходимо обратить на это особое внимание. Следует помнить, что при срабатывании сборки мусора необходимо наличие свободного места на диске, в размере 25% от общего объема сеансовых данных. Если этих 25% не будет, то кластер завершит свою работу аварийно.

Изменить расположение сеансовых данных, можно указав параметр –d в строке запуска службы агента сервера.

В данном каталоге, также расположены: реестр кластера, индекс полнотекстового поиска и журнал регистрации.

Влияние циклических ссылок на рост сеансовых данных

Чаще всего при выполнении процедуры ПоместитьВоВременноеХранилище, указывается идентификатор формы (ЭтаФорма.УникальныйИдентификатор). Как написано в документации, при указании идентификатора формы данные перестают считаться актуальными после того как форма будет закрыта.

Однако, если форма содержит в себе циклические ссылки (см. статью), то после закрытия формы она не уничтожается. Это приводит следующим отрицательным эффектам:

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

Необходимо стараться формировать отчеты СКД в фоновом режиме. Так как результат отчета помещается во временное хранилище фоновым заданием, то после завершения задания данный результат будет считаться неактуальным.

Методика анализа роста сеансовых данных

Сбор данных

Необходимо собрать технологический журнал:

Данный технологический журнал может занимать значительный объем. Поэтому необходимо располагать его на дисках имеющих достаточно свободного пространства, периодически переносить старые файлы журнала на другой диск и там архивировать (сохраняя структуру папок).

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

На основании данных, которые собраны в папках rmngr_*, необходимо сформировать csv файл вида:

В файле …/rmngr_7188/ 15063011. log есть строка:

Данная строка должна быть преобразована в строку:

Необходимо исключить из итогового файла строки с InBytes=0, т.к. они не представляют интереса, но занимают значительный объем.

На основании данных, которые собраны в папках rphost_*, необходимо сформировать csv файл вида:

В файле …/ rphost_1352 / 15063011 .log есть строка:

Данная строка должна быть преобразована в строку:

На основании данных, которые собраны в папках rphost_*, необходимо сформировать csv файл вида:

В файле …/ rphost_1352 /15063011.log есть строка:

Данная строка должна быть преобразована в строку:

В итоге должно получиться 3 файла: scall.csv, call.csv, conn.csv

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

Создание базы данных для анализа

Необходимо создать пустую базу данных (MS SQL Server), в которую добавить таблицы:

Затем, в эти таблицы необходимо загрузить данные из соответствующих csv файлов. Сделать это можно с помощью SQL Server Integration Services

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

Анализ работы с сеансовыми данными

TOP – 10 пользователей в разрезе процессов и времени

Запрос покажет топ-10 пользователей, которые поместили больше всего сеансовых данных в час. Затем необходимо разобраться с самым верхним (в текущем случае):

Т.е. в процессе rphost_1352 за час с 11-00 по 12-00 пользователь с идентификатором 518 записал в сеансовые данные 2 046 616 858 байт (2Гб).

Далее, необходимо найти все идентификаторы вызовов, которые записывал сеанс 518:

Rphost что за процесс

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

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

Архитектура кластера серверов 1С.

Основные возможности кластера серверов

  • может функционировать на одном или нескольких компьютерах (рабочих серверах);
  • на каждом рабочем сервере может функционировать один или несколько рабочих процессов, обслуживающих клиентские соединения в рамках данного кластера;
  • подключение новых клиентов к рабочим процессам кластера выполняется на основе анализа долгосрочной статистики загруженности рабочих процессов;
  • взаимодействие процессов кластера с клиентскими приложениями, между собой и с сервером баз данных осуществляется по протоколу TCP/IP;
  • процессы кластера сервера могут быть запущены как приложение, или как сервис.
Состав простейшего кластера серверов

В самом простом исполнении кластер серверов может быть расположен на одном компьютере. Также простейший кластер может состоять из одного рабочего процесса:

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

Агент сервера ragent.exe

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

Агент сервера и список кластеров обеспечивают работу сервера и кластеров, которые расположены на нем. Эти компоненты не входят в состав кластера серверов.

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

  • rmngr.exe (может быть один или несколько процессов);
  • реестр кластера;
  • rphost.exe (может быть один или несколько процессов).
Менеджер кластера rmngr.exe

Rmngr.exe управляет функционированием кластера . М о жет существовать несколько таких менеджеров в составе кластера. В любом случае один из этих процессов всегда будет являться главным менеджером кластера. Другие — дополнительными менеджерами. Сервер, на котором запущен главный менеджер кластера и находится реестр кластера, будет именоваться центральным сервером кластера . Менеджер кластера, в том числе, обеспечивает ведение реестра кластера.

Рабочий процесс rphost.exe.

Rphost.exe занимается обслуживанием непосредственно клиентских приложений, он взаимодействует с сервером БД (баз данных), в нем исполняются процедуры серверных модулей конфигурации.

Итак, теперь нам стала ясна роль и место рабочего процесса rphost.exe в конфигурации кластера серверов 1С:Предприятие.

Проблемы с rphost.exe

Теперь приступим к исследованию возможных неудобств в работе rphost.exe и вариантам их устранения.

rphost.exe грузит память и занимает процессорное время

Как видно на картинке, отображающем диспетчер задач, процесс rphost.exe достаточно сильно загружает память сервера и его процессор. Причем 1С не работает ни в режиме приложения, ни в режиме конфигурирования.

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

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

Как можно снизить расход ресурсов процессом rphost.exe

Версия платформы. Прежде всего стоит проверить версию платформы 1С. И, если платформа не актуальна, то обновить ее. Лучше в любом случае поддерживать платформу в актуализированном состоянии.

Фоновые задачи. Далее стоит проверить на предмет необходимости все фоновые задачи используемой конфигурации или нескольких конфигураций. В случае присутствия ненужных — их отключить или удалить. Делать это нужно аккуратно, вначале выполнив резервное копирование ИБ. Как сделать выгрузку ИБ можно посмотреть в статье: Как обновить сервер 1С 8.3 и платформу 1С 8.3. Как блокировать пользователей 1С. Как сделать выгрузку базы данных 1С. 1С Предприятие клиент-сервер. Операционная система Windows Server 2012 R2

Если в фоновых регламентированных задачах, по Вашему мнению нет необходимости, то можно отключить выполнение фоновых заданий непосредственно из mmc-консоли управления кластером серверов 1С.

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

Далее нужно авторизоваться в информационной базе.

После авторизации установите галочку возле опции «Блокировка регламентных заданий включена»

Полнотекстовый поиск (отключение, включение).

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

Заходим в главном меню, пункт «Все функции»

Далее находим «Управление полнотекстовым поиском».

Отключаем полнотекстовый поиск.

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

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

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

Для улучшения ситуации с загрузкой памяти процессом rphost.exe, установим в настройках кластера консоли администрирования кластера серверов 1С следующие параметры:

Если у Вас появились вопросы по статье или остались нерешенные проблемы обсудить их Вы можете на Форуме 1С Вопросы и ответы

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Превышен максимальный расход памяти сервера

Краткое содержание:

Что требуется сделать

  1. Подключиться к указанному серверу
  2. Запустить RamMap
  3. Найти процесс, который использовал всю доступную оперативную память. Стоит также смотреть на закладку File Summary.
  4. Найти причину
  5. Если это процесс rphost, то открываем консоль администрирования серверов 1С
  6. Переходим на страницу Сеансы
  7. Находим колонку Память (текущая)
  8. Упорядочиваем по колонке
  9. Записываем номера сеансов, которые использовали больше всего памяти
  10. Завершаем сеансы
  11. Проверяем, успело ли сработать условие перезапуска процессов кластера серверов
  12. Если есть сеансы, которые находятся в длительном клиент-серверном вызове, то записываем номера сеансов
  13. Завершаем сеансы, убеждаемся, что процессы успешно перезапустились.
  14. Убеждаемся, что памяти достаточно
  15. Если процесс rmngr и виновник не понятен, то снимаем дамп с помощью утилиты ProcDump
  16. Полученные дампы и технологические журналы (если собирались) отправляем в 1С с подробным описанием проблемы и симптомов
  17. Следует учитывать, что нет смысла отправлять дампы в 1С, если на сервере действительно очень мало доступной оперативной памяти, а rmngr при нормальной работе занимает ровно тот же самый объем
  18. Ищем в журнале регистрации полученные номера сеансов с целью выяснить сценарий, который выполнялся в момент воспроизведения проблемы. Анализируем.
  19. Проверяем, настроен ли перезапуск процессов кластера.

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

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

Нужно запустить batch file из директории, в которой расположен ProcDump (http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx)

echo Start dumping all rmngrs, rphosts, and ragents on this server.

Я уже писал несколько статей:

теперь немного подробнее:

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

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

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

Безопасный расход памяти за один вызов — позволяет контролировать расход памяти при серверном вызове, измеряется в байтах. Если вызов использует больше памяти чем положено, этот вызов будет завершен в рамках кластера 1С без перезапуска рабочего процесса (rphost.exe). Соответственно неудачник, который выполнил вызов сервера, утратит сеанс с базой 1С без влияния на работу других пользователей.

в одном ГБ — 1073741824 Байт, следовательно в 2 ГБ — 2147483648 Байта

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

Количество ИБ на процесс — позволяет изолировать информационные базы по рабочим процессам. По умолчанию у текущего кластера 1С было установлено значение — 8, но на протяжении нескольких часов работы сервер себя очень нестабильно, сеансы пользователей зависали. После изоляции каждой информационной базы (значение — 1) проблемы пропали.

Количество соединений на процесс — по умолчанию значение 128. Так как у текущей базы очень большая нагрузка фоновыми заданиями (расчет логистики, анализ прайсов, анализ конкурентов и прочее) было принято решение уменьшить количество до 25.

Немного изменились настройки и самого кластера 1С:

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

Режим распределения нагрузки — есть два варианта параметра: Приоритет по производительности — памяти сервера тратится больше и производительность выше, Приоритет по памяти — кластер 1С экономит память сервера.

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

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

Это снижает вероятность неправильной настройки сервера и понижает требования к квалификации админов.

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

Стабильность работы при использовании больших объемов памяти определятся новыми параметрами рабочего сервера.

Особенно интересен параметр «безопасный расход памяти за один вызов». Для тех кто плохо представляет что это такое — лучше не тренируйтесь на «продуктивной» базе. Параметр «Максимальный объем памяти рабочих процессов» позволяет при «переполнении» не обваливать весь рабочий процесс, а только один сеанс «с неудачником». «Объем памяти рабочих процессов, до которого сервер считается производительным» позволяет заблокировать новые соединения как только будет преодолен этот порог памяти.

Рекомендую изолировать рабочие процессы по информационным базам, к примеру указать параметр «Количество ИБ на процесс = 1″. При нескольких высоконагруженных базах это позволит уменьшить взаимное влияние как по надежности, так и по производительности.

Отдельный вклад в стабильность системы вносит «расходование» лицензий/ключей. В 8.3 появилась возможность использования «менеджера программных лицензий» напоминая менеджер «аладина». Цель — возможность вынести ключ на отдельную машину.

Реализован он в виде еще одного «сервиса» в менеджера кластера. Вы можете использовать к примеру «свободный» ноутбук. Добавьте его в кластер 1с 8.3, создайте на нем отдельный менеджер с сервисом «сервис лицензирования». В ноутбук можно воткнуть аппаратных hasp-ключ, или активировать программные лицензии.

Наибольший интерес для программистов должен представлять «Требования назначения функциональности».

Требования назначенной функциональности 1с

Так на ноутбуке с ключом защиты чтобы не запускать пользователей на сервер кластера надо добавить «требования» для объекта требования «Клиентское соединение с ИБ» — «Не назначать», т.е. запретить рабочим процессам данного сервера обрабатывать клиентские соединения.

Еще больший интерес предоставляет возможность запускать «только фоновые задания» на рабочем сервере кластера без сеансов пользователей. Таким образом можно высоконагруженные задачи (код) вынести на отдельный машины. При чем можно одно фоновое задание «закрытия месяца» через «Значение дополнительного параметра» запускать на одном компьютере, а фоновое задание «Обновление полнотекстового индекса» на другом.Уточнение происходит через указание «Значение дополнительного параметра». Например если указать BackgroundJob.CommonModule в качестве значения, то можно ограничить работу рабочего сервера в кластере только фоновыми заданиями с любым содержимым. Значение BackgroundJob.CommonModule. . — укажет конкретный код.

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

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

Отказоустойчивость сервера 8.2 достигается за счет:

  • Хранение информации о сеансе работы пользователя.
  • Пользователь не привязан больше к рабочему процессу.
  • Резервирование рабочих процессов в кластере.
  • Должно быть несколько рабочих процессов, в том числе резервируемые
  • Резервирование кластеров.

Указывается запасной кластер, при подключении — перечисляются в строке соединения

Это позволяет обеспечить непрерывность работы!

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

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

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

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

Guesto notes

  • 1С:Предприятие 8.3;
  • Клиент-серверный вариант работы;
  • Управляемое приложение.

Загрузка большого(over 200 000 записей,

3 Гб) файла XML обработкой «Универсальный обмен данными в формате XML» получаем ошибку: «Превышен максимальный расход памяти сервера за один вызов».

Данная ошибка вызывается из-за настроек сервера 1С. В настройках сервера в параметре «Безопасный расход памяти за один вызов» по умолчанию указано значение «0».

Нулевое значение параметров «Максимальный объем памяти рабочих процессов» и «Безопасный расход памяти за один вызов» значит использование величины по умолчанию, которая равна 80% объема физической оперативной памяти и 10% от «Максимального объема памяти рабочих процессов» соответственно.

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

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

Комментарии 2

Я решил проблему простенько, помимо изменения параматра безопасного расхода памяти, так же увеличил файл подкачки и сам объем памяти рабочих процессов до моих предельных 4 Гб, программа обновилась!

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

Rphost что за процесс

PHP, Java, Delphi, 3D

Оптимизация скорости работы «1С:Підприємство». Процесс «1С:Підприємство» rmngr.exe грузит процессор

Один из серверов «1С:Підприємство», который я обслуживаю, очень странно себя вел. Загрузка процессора на машине с сервером «1С:Підприємство» почти всегда была 100%, даже когда на нем никто не работал. Базы хранились в MSSQL, их было относительно много, но реально людей, которые с ними работали — мало. Одновременно работало не больше 10-15-ти пользователей в очень вялом режиме.

Этот сервер привлек мое внимание сразу же, как только я стал с ним работать. Предыдущий администратор безрезультатно бился над производительностью, приобрел 2 внешних корзины для отдельного рейда под базы данных mssql и временные данные пользователя «1С:Підприємство», но существующую проблему по загрузке процессора это не решало, хотя немножко разгрузило диски, но реальная проблема была не в них.

На сервере размещались примерно 30-35 баз, в которых работали по 1-2 человека и пару баз были, где работали по 3-5 человек одновременно. Все это крутилось вместе с MSSQL сервером на отдельном железном сервере с одним стареньким ксеоном и 32 гб оперативы. В принципе, для этих задач железо было более чем.

Первое, на что я обратил внимание, это то, что процессор был загружен даже ночью, когда на сервере никто не работал. Полез в консоль администратора смотреть, что нагружает процессор. Оказалось, что это фоновые задачи. Для большинства баз они были не нужны и все лишнее отключил. Нагрузка процессора сразу упала до приемлемого уровня в 60-70%, а диски вообще полностью разгрузились. Я про сервер забыл на какое-то время.

Снова к нему вернулся, когда пользователи стали жаловаться на очень медленную работу баз «1С:Підприємство». Процессор к тому времени почти всегда был загружен на 100%. Лишних фоновых задач уже не было. Надо было разбираться более внимательно, в чем тут проблема.

Разбираемся что конкретно в rmngr.exe грузит процессор

Загрузку процессора в равной степени давал процесс rmngr.exe и rphost.exe. Rphost уже ранее был настроен и оптимизирован. Вот такие настройки дали стабильную работу без необходимости перезапускать сервер месяцами:

Нагрузку rphost давал за счет оставшихся фоновых задач и что с ним еще сделать, я не знал. А с rmngr хотелось разобраться и узнать, что конкретно пожирает процессорное время. В этом процессе собраны все процессы менеджера кластера:

Есть возможность разделить сервисы менеджера кластера по разным системным процессам rmngr.exe и по pid определить, какая именно служба нагружает процессор. Включить такое разделение можно в свойствах рабочего сервера:

После того, как вы поставите галку, агент сервера «1С:Підприємство» сам перезапустится с новыми настройками. После этого в диспетчере задач у вас будет порядка 15-ти процессов rmngr.exe с разными pid. Смотрите, какой из процессов больше всего использует процессор и в консоли управления «1С:Підприємство» в разделе Менеджеры кластера по pid смотрите описание процесса.

В моем случае это был сервис журнала регистраций. Чтобы это узнать, дважды щелкните мышкой по процессу с необходимым pid:

Пол дела сделали, нашли виновника тормозов. Я скрины делал, когда уже решил проблему, так что у меня нагрузки нет.

Сервис журнала регистраций «1С:Підприємство» нагружает процессор

Я выяснил, что конкретно дает чрезмерную нагрузку на сервер. Посмотрел на объем журналов регистраций. У некоторых баз он достигал размера в 10-15 гигов. После чистки серверу стало заметно легче, нагрузка снова опустилась, но где-то до 80-90% и я на несколько месяцев забыл про сервер.

Он напомнил о себе тормозами и загрузкой процессора в 100%. Проделанные выше операции уже не давали результата. Баз стало немного больше и нужно было думать, как разгрузить сервер. Он работал на все 100% даже в нерабочее время, когда на нем не было ни одного реального пользователя. Сервис журнала регистраций потреблял 30-40% процессорного времени.

Я стал внимательно шерстить интернет на заданную тему и нашел несколько заметок. Находились люди, которые обратили внимание на чрезмерную нагрузку сервиса журнала регистраций. Как вариант решения проблемы они предлагали откатиться на старую версию ведения логов lgf вместо новой lgd. Я не знаю, что принципиально изменилось в формате ведения лога журнала регистраций, но по отзывам попробовавших, нагрузка на процессор падала. Забегая вперед скажу, что мне этот совет помог.

Переводим сервер на старый вариант ведения логов журнала регистраций

Какой-то одной настройки или автоматического решения для перевода лога журнала регистраций в старый формат lgf нет. Чтобы использовать старый формат необходимо остановить службу Агента Сервера 1С:Предприятия. Затем отправиться в папку C:Program Files (x86)1cv8srvinforeg_1541, выбрать по id базу, в которой хотите изменить формат лога. У меня баз было много, мне лениво стало вручную в каждой менять формат. Я выбрал базы с самым большим объемом и изменил формат только у них.

В каждой папке с базой есть каталог 1Cv8Log, а в нем 2 файла: 1Cv8.lgd и 1Cv8.lgd-journal. Их надо удалить и вместо них в этой папке создать пустой файл 1Cv8.lgf. Проделать такую операцию нужно со всеми базами, где будете менять формат лога. Старый не обязательно удалять, лучше его перенести куда-нибудь, вдруг пригодятся записи из него.

После этого можно запускать службу Агента Сервера 1С:Предприятия. После перехода на старый формат журнала регистрации, нагрузка процесса rmngr.exe упала практически до 0, а сервера в целом до приемлемых 40-60%.

Заключение

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


Источник: cloud-script.ru