Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Реализовано в версии 8.3.15.1489.
Мы реализовали новый алгоритм перезапуска рабочих процессов, сделали настройки кластера более гибкими. Эти изменения позволяют уменьшить влияние проблем потребления памяти на работу кластера серверов 1С:Предприятия.
Кластер в некоторых случаях перезапускает свои рабочие процессы для того, чтобы обеспечивать бесперебойную работу пользователей с информационными базами. Перезапуск может быть вызван такими причинами, как потребление значительных объемов памяти в течение длительного времени или длительный период непрерывной работы процесса.
Во время перезапуска любого рабочего процесса существует интервал времени, в течение которого кластер не может обслуживать те соединения, которые есть в этом процессе. Для пользователей это выражается в заметной паузе, которая может достигать десятков секунд, и которая может доставлять ощутимые неудобства.
Суть наших изменений заключается в том, чтобы максимально снизить время, в течение которого рабочий процесс не может обслуживать пользователей. Для этого мы теперь позволяем старому процессу работать, и параллельно с этим готовим новый процесс. Когда всё готово, мы быстро перебрасываем соединения, и удаляем старый процесс.
Если говорить более подробно, то процедура перезапуска рабочих процессов выглядит теперь следующим образом:
В результате реализации такого алгоритма работы нам удалось существенно сократить время неработоспособности соединений при их переброске на новый рабочий процесс. Для пользователей это выражается в том, что теперь исчезла пауза в работе, которую они замечали раньше.
Например, раньше, в зависимости от конфигурации, пауза в работе могла составлять от 2 до 120 секунд. Теперь период неработоспособности соединений составляет от 0,05 до 0,6 секунды.
Также мы реализовали отображение этапов перезапуска рабочих процессов в технологическом журнале. Теперь вы можете увидеть в нем следующие события и сообщения:
Раньше вы могли контролировать то, как кластер потребляет память, и могли настраивать параметры автоматического перезапуска рабочих процессов для её освобождения. Однако эти настройки были относительно грубыми и в сложных случаях не позволяли использовать оборудование настолько эффективно, насколько вам бы хотелось.
Например, параметр, ограничивающий потребление памяти, был один, и он применялся ко всем рабочим процессам. Если ваш кластер состоял из многих рабочих серверов с разным объёмом оперативной памяти, такая настройка, очевидно, имела какое-то усреднённое значение, ориентированное на самые слабые серверы.
Другое неудобство – это оценка потребляемого объёма памяти. Кластер подсчитывал только ту память, которую занимают рабочие процессы. Это, без сомнения, основной объём памяти. Однако есть ситуации, когда и менеджеры потребляют довольно значительное количество памяти. Например, если конфигурация использует большое количество управляемых блокировок.
Чтобы преодолеть все эти неудобства, мы внесли ряд изменений как в настройки кластера, так и в логику его работы.
Теперь при подсчете оперативной памяти, занимаемой на каждом рабочем сервере, мы учитываем объём, занимаемый как рабочими процессами, так и менеджерами кластера. Поэтому вы можете проще и точнее выставлять значения параметров, которые ограничивают потребление памяти.
Мы ликвидировали у кластера настройки, которые позволяют управлять потреблением памяти (Допустимый объем памяти и Интервал превышения допустимого объема памяти). Для обеспечения обратной совместимости их значения останутся в реестре кластера, и при обратном переходе на предыдущую версию будут использоваться.
Управление потреблением памяти реализовано теперь на уровне рабочих серверов. Для этого у них появились новые свойства:
Работают эти свойства следующим образом (в порядке увеличения критичности ситуации):
ВременноДопустимыйОбъемПамятиПроцессов. Если рабочий сервер «потребил» памяти больше, чем вы указали в этом параметре, то на этот рабочий сервер перестают назначаться новые соединения.
ПериодПревышенияВременноДопустимогоОбъемаПамятиПроцессов. Если через количество секунд, которое вы указали в этом параметре, рабочий сервер все ещё продолжает превышать ВременноДопустимыйОбъемПамятиПроцессов, то будут перезапущены рабочие процессы с наибольшим потреблением памяти. Эти процессы будут перезапущены «естественным» образом, так, как это описывалось выше. Будет перезапущено такое количество процессов, чтобы оставшиеся процессы не потребляли больше, чем ВременноДопустимыйОбъемПамятиПроцессов.
КритическийОбъемПамятиПроцессов. Это «красная кнопка». Если рабочий сервер «потребил» памяти больше, чем вы указали в этом параметре, то освобождение памяти будет выполнено немедленно. Процессы с наибольшим потреблением памяти будут остановлены аварийно, и затем запущены заново. Количество таких процессов будет определяться так же, как и в предыдущем случае. При этом, по умолчанию, дамп памяти записываться не будет, т.к. это управляется новым параметром кластера ЗаписыватьДампПриЗавершенииПоПревышениюПамяти.
Кластеру мы добавили новый параметр ЗаписыватьДампПриЗавершенииПоПревышениюПамяти. По умолчанию этот параметр имеет значение Ложь.
Этот параметр не требует от вас какой-то особенной настройки. Причина его появления заключается в следующем. Раньше при аварийном завершении рабочего процесса дамп всегда записывался. Однако не во всех ситуациях этот дамп приносит пользу. В частности, если рабочий процесс завершился аварийно в результате превышения объёма памяти, дамп будет практически бесполезен. В настоящее время его анализ не позволит выяснить причину расхода памяти.
Таким образом, сейчас эта настройка просто заботится о том, чтобы не «засорять» диск. А в будущем она позволяет включить запись дампов по превышению памяти, если в этом возникнет необходимость.
Мы надеемся, что новые настройки помогут вам более эффективно использовать ресурсы рабочих серверов, и уменьшат влияние проблем потребления памяти на работу кластера. А благодаря новому алгоритму перезапуска рабочих процессов пользователи смогут работать «гладко», без пауз и «подвисаний».
