Содержание
Краткое содержание:
Что требуется сделать
- Подключиться к указанному серверу
- Запустить RamMap
- Найти процесс, который использовал всю доступную оперативную память. Стоит также смотреть на закладку File Summary.
- Найти причину
- Если это процесс rphost, то открываем консоль администрирования серверов 1С
- Переходим на страницу "Сеансы"
- Находим колонку Память (текущая)
- Упорядочиваем по колонке
- Записываем номера сеансов, которые использовали больше всего памяти
- Завершаем сеансы
- Проверяем, успело ли сработать условие перезапуска процессов кластера серверов
- Если есть сеансы, которые находятся в длительном клиент-серверном вызове, то записываем номера сеансов
- Завершаем сеансы, убеждаемся, что процессы успешно перезапустились.
- Убеждаемся, что памяти достаточно
- Если процесс rmngr и виновник не понятен, то снимаем дамп с помощью утилиты ProcDump
- Полученные дампы и технологические журналы (если собирались) отправляем в 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
- "старый" процесс 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С, настройке сервера MS SQL при работе в среде 1С
1. Рекомендации по настройке кластера 1С 8.3
Обратите внимание, что настройки кластера отвечают за настройки всех серверов принадлежащих настраиваемому кластеру. Кластер подразумевает работу нескольких физических или виртуальных серверов, работающих с одними и теми же информационными базами.
Интервал перезапуска – отвечает за частоту перезапуска рабочих процессов кластера. Этот параметр необходимо выставлять при круглосуточной работы сервера. Рекомендуется частоту перезапуска связывать с технологическим циклом информационных баз кластера. Обычно это каждые 24 часа (86400 сек). Как известно, рабочие процессы серверов 1С обрабатывают и хранят рабочие данные.
Автоматический перезапуск был разработан в платформе «для минимизации отрицательных последствий фрагментации и утечки памяти в рабочих процессах». На ИТС есть даже информация о том, как организовать перезапуск рабочих процессов по другим параметрам (объем памяти, занимаемые ресурсы и т.п.).
Допустимый объем памяти – защищает сервера 1С от перерасхода памяти. При превышении процессом этого объема в интервале превышения допустимого объема, процесс перезапускается. Можно рассчитать как максимальный размер памяти, занимаемый процессами «rphost» в периоды пиковой нагрузки серверов. Также стоит установить небольшой интервал превышения допустимого объема.
Допустимое отклонение количества ошибок сервера. Платформа рассчитывает среднее количество ошибок сервера по отношению к числу обращений к серверу в течение 5 минут. Если это отношение превысит допустимое, то рабочий процесс считается «проблемным», и может быть завершен системой, если установлен флаг «Принудительно завершать проблемные процессы».
Выключенные процессы останавливать через. При превышении допустимого объема памяти, рабочий процесс не завершается сразу, а становится «выключенным», чтобы было время «перенести» рабочие данные без потери на новый запущенный рабочий процесс. Если указан этот параметр, то «выключенный» процесс в любом случае завершится по истечении этого времени. Если наблюдаются «зависшие» рабочие процессы в работе сервера 1С, то можно стоит этот параметр на 2-5 минут.
Эти настройки устанавливаются для каждого сервера 1С индивидуально.
Максимальный объем памяти рабочих процессов – это объем совокупной памяти, которую могут занимать рабочие процессы (rphost) на текущем кластере. Если параметр установлен в «0», то занимает 80% оперативной памяти сервера. «-1» – без ограничений. Когда на одном сервере работают СУБД и сервер 1С, им нужно делить между собой оперативную память. Если в процессе эксплуатации обнаружится, что серверу СУБД не хватает памяти, то можно ограничить память, выделяемую серверу 1С с помощью этого параметра. Если СУБД и 1С разделены по серверам, то имеет смысл рассчитать этого параметр по формуле:
«Max объем» = «Общая оперативная память» – «Оперативная память ОС»;
«Оперативная память ОС» рассчитывается по принципу 1 Гб на каждые 16 Гб оперативной памяти сервера
Безопасный расход памяти за один вызов. В общем случае, отдельные вызовы не должны занимать всю оперативную память, выделенную рабочему процессу. Если параметр установлен в «0», то объем безопасного расхода будет равен 5 % от «Максимального объема памяти рабочих процессов». «-1» – без ограничения, что крайне не рекомендуется. В большинстве случаев этот параметр лучше оставлять «0».
С помощью параметров «Количество ИБ на процесс» и «Количество соединений на процесс» можно управлять распределением работы сервера 1С по рабочим процессам. Например, запускать под каждую информационную базу отдельный «rphost», чтобы в случае «падений» процесса, отключались только пользователи одной базы. Эти параметры стоит подбирать индивидуально под каждую конфигурацию сервера.
2. Рекомендации по настройке СУБД MS SQ
Ограничение на использование оперативной памяти сервером СУБД – У сервера СУБД MS SQL есть одна замечательная особенность – он любит загружать базы, с которыми ведется активная работа в оперативную память полностью. Если его не ограничивать, то он заберет себе всю оперативную память, какую только сможет.
- Если сервер 1С:Предприятия установлен вместе с Microsoft SQL Server, то верхний порог памяти необходимо уменьшить на величину, достаточную для работы сервера 1С.
- Если на сервере работает только СУБД, то для СУБД по формуле:
«Память СУБД» = «Общая оперативная память» – «Оперативная память ОС»;
Shared memory – об этом параметре известно много, но до сих пор встречается, что про него забывают. Выставляем в «1», если сервер 1С и СУБД работают на одном физическом или виртуальном сервере. Кстати, работает, начиная с платформы 8.2.17.
Max degree of parallelism – определяет, сколько процессоров используется при выполнении одного запроса. СУБД распараллеливается получение данных при выполнении сложных запросов на несколько потоков. Для 1С рекомендуется устанавливать в «1», то есть одним потоком.
Авторасширение файлов БД – определяем шаг в МБ, с которым «расширяется» файл базы данных. Если шаг будет маленький, то при активном росте БД, частые расширения приведут к дополнительной нагрузке на дисковую систему. Лучше установить в 500 – 1000 МБ.
Реиндексация и дефрагментация индексов – рекомендуется делать дефрагментацию/реиндексацию хотя бы раз в неделю. Реиндексация блокирует таблицы, поэтому лучше запускать в нерабочее время или периоды минимальной нагрузки. Нет смысла делать дефрагментацию после перестроения индекса (реиндексации). По рекомендации Microsoft дефрагментацию делают в том случае, если фрагментация индекса не превышает 30 %. Если выше, рекомендуется сделать реиндексацию.
Обновление статистики – рекомендуется обновлять статистику хотя бы 1 раз в день. Статистика отвечает за производительность выполнения запросов.
План электропитания – в настройках электропитания операционной системы установить на высокую производительность.
Ставя очередное обновление Бухгалтерии получил ошибку "Я работаю только на 8.3.4", ну вот. пришло время поставить 8.3.4. и так:
Процесс скачивания и установки новой платформы я описывать не буду, там все просто.
Служба Агент Сервера 1С
По умолчанию он ставиться на порт 1540, а там у меня крутится 8.2, поэтому меняем в ветке рееста
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices1C:Enterprise 8.3 Server Agent Параметр ImagePath
меняем номера портов, добавляя смещение: "C:Program Files1cv88.3.4.365in
agent.exe" -srvc -agent -regport 1741 -port 1740 -range 1660:1691 -d "C:Program Files1cv8srvinfo"
Запускаем Агента и Открываем консоль Администрирования серверов 1С и создаем кластер 8.3
Указал имя сервера и настроил на порт 1740 (на 1540 работает 8.2) 
Создаем кластер + чуток оптимизировал( У меня всего небольшой ОДИН сервер, поэтому — указываю Интервал перезапуска рабочих процессов и объем памяти. т.к у меня один сервер — уровень отказоустойчивости — 0) 
Теперь подробнее:
1. Интервал перезапуска: 86400 сек (24 часа). Момент перезапуска не регламентируется, видимо с момента установки параметров, либо запуска сервера приложений.
2. Также можно указать допустимый объем памяти: 3000000 Кб (3 Гб) — Для сервера с 4 ГБ оперативы, Если ее меньше, то не заполняйте этот параметр!.
3. Интервал превышения допустимого объема памяти — это непрерывный интервал времени превышения допустимого объема памяти, после которого сервер перезапустит процесс. Если указано 0 сек — будет ждать вечно.
4. Количество Рабочих процессов расчитывается автоматически на основании Ваших настроек
5. Уровень отказоустойчивости можно задавать уровень отказоустойчивости кластера как количество рабочих серверов, которые могут одновременно выйти из строя, и это не приведет к аварийному завершению работы пользователей. Резервные сервисы запускаются автоматически в количестве, необходимом для обеспечения заданной отказоустойчивости; в реальном режиме времени выполняется репликация активного сервиса на резервные.
6. Режим распределения нагрузки, который можно использовать либо для повышения производительности системы вцелом, либо использовать новый режим «экономии памяти», который позволяет работает «с ограниченной памятью» в случаи если используемая конфигурация «любит отъедать память».
Рабочий сервер
Сервер у меня простенький, 2 Gb оперативы всего и на нем будет всего 2 базы, поэтому настрою его так: 
параметр Количество ИБ на процесс ставлю равным 1, т.е. хочу чтобы для каждой ИБ запускался свой процесс — это позволит уменьшить взаимное влияние как по надежности, так и по производительности. Вы же настраивате под характеристики своего сервера!
Информационная база
Добавляю ИБ: 
В стартере пописываю базу: 
Требования назначения функциональности
Я у себя это не настраиваю но думаю надо сказать об этом:
Управление кластером заключается в том, что администратор определяет состав компьютеров (рабочих серверов), на которых размещается кластер. Кроме этого (при необходимости) он может определить "требования" к ним: какие сервисы и соединения с информационными базами должны работать на каждом из рабочих серверов. Менеджеры кластера и рабочие процессы запускаются автоматически, исходя из назначенных "требований". "Требования" к рабочим серверам могут быть заданы интерактивно, из консоли администрирования кластера, или программно, из встроенного языка.
Так на ноутбуке с ключом защиты чтобы не запускать пользователей на сервер кластера надо добавить «требования» для объекта требования «Клиентское соединение с ИБ» — «Не назначать», т.е. запретить рабочим процессам данного сервера обрабатывать клиентские соединения. Еще больший интерес предоставляет возможность запускать «только фоновые задания» на рабочем сервере кластера без сеансов пользователей. Таким образом можно высоконагруженные задачи (код) вынести на отдельный машины. При чем можно одно фоновое задание «закрытия месяца» через «Значение дополнительного параметра» запускать на одном компьютере, а фоновое задание «Обновление полнотекстового индекса» на другом. Уточнение происходит через указание "Значение дополнительного параметра". Например если указать BackgroundJob.CommonModule в качестве значения, то можно ограничить работу рабочего сервера в кластере только фоновыми заданиями с любым содержимым. Значение BackgroundJob.CommonModule..- укажет конкретный код.
Профили безопасности
Профили безопасности служат для того, чтобы запретить прикладному решению выполнять действия, которые могут быть потенциально опасны для функционирования кластера серверов.
Администратор кластера может назначить любой информационной базе один из существующих в кластере профилей безопасности. И тогда потенциально опасная функциональность прикладного решения будет ограничена в тех пределах, которые описаны в этом профиле.
Стандартно, после создания, профиль безопасности запрещает выполнение всех потенциально опасных действий:
-обращение к файловой системе сервера;
-запуск COM-объектов;
-использование внешних компонентов 1С:Предприятия;
-запуск внешних обработок и отчётов;
-запуск приложений, установленных на сервере;
-обращение к ресурсам Интернета.
Таким образом защититься от нежелательных действий незнакомого прикладного решения очень просто: нужно создать пустой профиль безопасности и назначить его информационной базе. Далее, если есть необходимость, можно расширять этот профиль, описывая в нём действия, которые разрешается выполнять прикладному решению.
Расположение служебных файлов менеджера кластера в 1С Предприятии 8.3
Если при установке системы! «1С:Предприятие» был выбран вариант запуска сервера «1С:Предприятия» как сервиса, то первый запуск агента сервера будет выполнен еще в процессе установки системы. При этом сервис будет запущен от имени пользователя, выбранного в диалоге установки системы, но служебные файлы кластера серверов будут расположены в каталоге srvinfo (в параметрах сервиса будет в явном виде указан ключ запуска -d).
Если при установке системы «1С:Предприятие» был выбран вариант запуска сервера как приложения, то запуск сервера в процессе установки системы не выполняется; агента сервера необходимо запустить самостоятельно, после того как установка системы будет закончена. При этом если ключ запуска -d указан не будет, служебные файлы кластера серверов будут расположены в каталоге по умолчанию: %USERPROFILE%LocalSettingsApplicationDatalClCv8 (%LOCALAPPDATA%lClCv8 для ОС WindowsVista и старше).
ВНИМАНИЕ! Если однажды на данном центральном сервере уже был создан кластер, то при смене варианта запуска агента сервера (сервис, приложение) или при смене пользователя, от имени которого работает агент сервера, всегда следует заботиться о правильном указании пути к каталогу служебных файлов кластера серверов. Если в процессе запуска агент сервера не обнаружит список кластеров, он создаст новый кластер на данном сервере.
В операционной системе Linux служебные файлы кластера серверов будут расположены в папке /home/usrlcv8/.lcv8/lC/lcv8 (или сокращенный вариант записи —
