Заметки из Зазеркалья

22.02.2019

Развитие кластера серверов

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

Реализовано в версии 8.3.15.1489.

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

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

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

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

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

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

  • Кластер выключает старый рабочий процесс. При этом процесс продолжает работать, но не принимает новые информационные базы. Это значит, что:
    • процесс продолжает обслуживать старые соединения с информационными базами,
    • процесс принимает новые соединения с теми информационными базами, с которыми есть старые соединения,
    • процесс не принимает новые соединения с другими информационными базами.
  • Кластер регистрирует новый рабочий процесс и запускает его.
  • В новом рабочем процессе создаются контексты всех информационных баз, с которыми работает старый процесс, загружаются конфигурации этих баз. Для этого кластер запускает системные фоновые задания, которые обладают следующими особенностями:
    • они не учитывают требования назначения функциональности,
    • эти задания вы можете видеть в списке соединений с идентификатором SystemBackgroundJob и названием Системное фоновое задание,
    • вы можете прервать выполнение этих заданий средствами администрирования,
    • эти задания не имеют сеанса и не отображаются в журнале регистрации.
  • После того, как все конфигурации загружены в новый процесс, старый процесс перестаёт принимать любые новые соединения, и кластер перебрасывает все его старые соединения в новый процесс.
  • После того, как все соединения будут переброшены, или после окончания таймаута, заданного свойством Выключенные процессы останавливать через, кластер завершает старый рабочий процесс и отменяет его регистрацию в кластере.

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

Например, раньше, в зависимости от конфигурации, пауза в работе могла составлять от 2 до 120 секунд. Теперь период неработоспособности соединений составляет от 0,05 до 0,6 секунды.

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

  • Event=Process is switched off – процесс выключен,
  • Event=Process become disable - процесс начал ждать готовности преемника,
  • Event=Register rphost - зарегистрирован новый процесс и установлено свойство ProcessID в блокировке старого,
  • Txt=Run process - запущен новый процесс,
  • Event=Start warm up contexts - получен список контекстов выключенного процесса и передан новому,
  • Event=Start loading infobase contexts - начинается загрузка контекстов в новый процесс,
  • Event=Completed loading infobase context - загружен контекст в новый процесс,
  • Event=Completed loading the last infobase context – все контексты загружены в новый процесс,
  • Event=Process become to deport connections - старый процесс начал перекидывать соединения,
  • Txt=Process terminated - старый процесс завершился.

Более точный и простой контроль потребления памяти

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

Например, параметр, ограничивающий потребление памяти, был один, и он применялся ко всем рабочим процессам. Если ваш кластер состоял из многих рабочих серверов с разным объёмом оперативной памяти, такая настройка, очевидно, имела какое-то усреднённое значение, ориентированное на самые слабые серверы.

Другое неудобство – это оценка потребляемого объёма памяти. Кластер подсчитывал только ту память, которую занимают рабочие процессы. Это, без сомнения, основной объём памяти. Однако есть ситуации, когда и менеджеры потребляют довольно значительное количество памяти. Например, если конфигурация использует большое количество управляемых блокировок.

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

Подсчет занимаемой памяти

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

Управление потреблением памяти на уровне рабочих серверов

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

Управление потреблением памяти реализовано теперь на уровне рабочих серверов. Для этого у них появились новые свойства:

  • ВременноДопустимыйОбъемПамятиПроцессов,
  • ПериодПревышенияВременноДопустимогоОбъемаПамятиПроцессов,
  • КритическийОбъемПамятиПроцессов.

Работают эти свойства следующим образом (в порядке увеличения критичности ситуации):

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

ПериодПревышенияВременноДопустимогоОбъемаПамятиПроцессов. Если через количество секунд, которое вы указали в этом параметре, рабочий сервер все ещё продолжает превышать ВременноДопустимыйОбъемПамятиПроцессов, то будут перезапущены рабочие процессы с наибольшим потреблением памяти. Эти процессы будут перезапущены «естественным» образом, так, как это описывалось выше. Будет перезапущено такое количество процессов, чтобы оставшиеся процессы не потребляли больше, чем ВременноДопустимыйОбъемПамятиПроцессов.

КритическийОбъемПамятиПроцессов. Это «красная кнопка». Если рабочий сервер «потребил» памяти больше, чем вы указали в этом параметре, то освобождение памяти будет выполнено немедленно. Процессы с наибольшим потреблением памяти будут остановлены аварийно, и затем запущены заново. Количество таких процессов будет определяться так же, как и в предыдущем случае. При этом, по умолчанию, дамп памяти записываться не будет, т.к. это управляется новым параметром кластера ЗаписыватьДампПриЗавершенииПоПревышениюПамяти.

Управление записью дампа

Кластеру мы добавили новый параметр ЗаписыватьДампПриЗавершенииПоПревышениюПамяти. По умолчанию этот параметр имеет значение Ложь.

Этот параметр не требует от вас какой-то особенной настройки. Причина его появления заключается в следующем. Раньше при аварийном завершении рабочего процесса дамп всегда записывался. Однако не во всех ситуациях этот дамп приносит пользу. В частности, если рабочий процесс завершился аварийно в результате превышения объёма памяти, дамп будет практически бесполезен. В настоящее время его анализ не позволит выяснить причину расхода памяти.

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

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

Теги: кластер 

Рассказать друзьям: