Интервал перезапуска рабочих процессов
Коллеги, добрый день!
Вопрос такой стоит ли менять значение по умолчанию в настройка кластера (перезапускать рабочие процессы) с 0 на например раз в сутки? На ИТС нашел только описание данного параметра:
"Интервал перезапуска __ секунд
Интервал времени после запуска процесса, по истечении которого рабочий процесс перезапускается. Нулевое значение означает, что рабочие процессы не будут перезапускаться автоматически."
В интернетах пишут так:
Информация с различных источников:
"Интервал перезапуска - это время по прошествии которого, рабочий процесс автоматически будет перезапущен. рабочий процесс выключается, и запускается новый рабочий процесс. Выключенный процесс обслуживает существующие соединения и не устанавливает новые. Новые соединения устанавливаются только с включенными рабочими процессами, в том числе и перезапущенными. Выключенный рабочий процесс завершается после того, как все соединения с ним разорваны. Отсчет времени идет с момента установки этого значения."
Т.е. по идеи, если всё хорошо, то должен происходить "мягкий" перезапуск с плавным переходом пользователей на новые процессы.
В книжке "Эксперта по тех. вопросам" говорится о необходимости перезапусков и использования для этого именно данного метода. Однако, есть и другие мнения, например товарищ gilv, рекомендует установить параметр в 0, а вместо этого перезагружать сервер (.
В связи с этим, хочется узнать как у коллег и на практике: перезапускаете ли вы рабочие процессы, используете ли для этого "интервал перезапуска"? Или планировщиком ночью рубите службы сервера 1С? Заметен ли для пользователей перезапуск рабочих процессов, в случае использования консоли кластеров ("интервал перезапуска")? Планирую использовать "интервал перезапуска" в значение 86400 (24 часа) установив его в то время, когда нагрузка на сервер минимальна. Заранее спасибо за участие
Вопрос такой стоит ли менять значение по умолчанию в настройка кластера (перезапускать рабочие процессы) с 0 на например раз в сутки? На ИТС нашел только описание данного параметра:
"Интервал перезапуска __ секунд
Интервал времени после запуска процесса, по истечении которого рабочий процесс перезапускается. Нулевое значение означает, что рабочие процессы не будут перезапускаться автоматически."
В интернетах пишут так:
Информация с различных источников:
"Интервал перезапуска - это время по прошествии которого, рабочий процесс автоматически будет перезапущен. рабочий процесс выключается, и запускается новый рабочий процесс. Выключенный процесс обслуживает существующие соединения и не устанавливает новые. Новые соединения устанавливаются только с включенными рабочими процессами, в том числе и перезапущенными. Выключенный рабочий процесс завершается после того, как все соединения с ним разорваны. Отсчет времени идет с момента установки этого значения."
Т.е. по идеи, если всё хорошо, то должен происходить "мягкий" перезапуск с плавным переходом пользователей на новые процессы.
В книжке "Эксперта по тех. вопросам" говорится о необходимости перезапусков и использования для этого именно данного метода. Однако, есть и другие мнения, например товарищ gilv, рекомендует установить параметр в 0, а вместо этого перезагружать сервер (.
В связи с этим, хочется узнать как у коллег и на практике: перезапускаете ли вы рабочие процессы, используете ли для этого "интервал перезапуска"? Или планировщиком ночью рубите службы сервера 1С? Заметен ли для пользователей перезапуск рабочих процессов, в случае использования консоли кластеров ("интервал перезапуска")? Планирую использовать "интервал перезапуска" в значение 86400 (24 часа) установив его в то время, когда нагрузка на сервер минимальна. Заранее спасибо за участие
Прикрепленные файлы:
По теме из базы знаний
- Рекомендации по оптимальной настройке кластера 1С, настройке сервера MS SQL при работе в среде 1С
- Как настроить сервер 1С по умолчанию для ПРОФ лицензии после 10.09.2019
- Описание почти всех событий технологического журнала
- Ошибка аутентификации клиента средствами операционной системы: Аутентификационный контекст клиента отсутствует в рабочем процессе
- Объединение идентичных баз ЗУП
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)рестарт будет происходить не с момента установки этого значения, а с момента старта каждого конкретного rphost-а, поэтому предсказать когда это произойдет и все сеансы этого рпхоста подвиснут на время переключения на новый процесс практически нереально (переключение поменялось в 8.3.15 и теперь мнгновенно).
Поэтому устанавливать этот параметр отличным от 0 не нужно, из практики.
Про рестарты сервера - на нагруженных системах или при периодических проблемах аля невозможности входа в базу, агент сервера нужно останавливать с остановкой всех дочерних процессов, чисткой временных папок и сеансовых данных, например раз в сутки ночью, вся процедура занимает максимум 5 минут
Если же нет проблем такого рода, то лучше не трогать систему
Поэтому устанавливать этот параметр отличным от 0 не нужно, из практики.
Про рестарты сервера - на нагруженных системах или при периодических проблемах аля невозможности входа в базу, агент сервера нужно останавливать с остановкой всех дочерних процессов, чисткой временных папок и сеансовых данных, например раз в сутки ночью, вся процедура занимает максимум 5 минут
Если же нет проблем такого рода, то лучше не трогать систему
Неоднократно пытался использовать эту хрень, как замену рестарта сервера. Так вот - это не замена. Вернее, замена неполноценная.
В идеальном мире должно работать все хорошо. Т.е. создается новый рабочий процесс, на него переползают пользовательские сессии, старый прибивается.
На практике бывают проблемы. Например, старый процесс удаляться не хочет. Это типа лечит галка его принудительного убития в этом случае. Но в рабочее время это тоже не всегда происходит без проблем для пользователей, как и поднятие новых процессов и миграция сессий. Всякое бывает. А надеяться на стабильность расписания нельзя, потому что его нет. И момент перезапуска может легко сместиться по ряду причин.
Потом, регулярный перезапуск рабочих процессов - это профилактика лишь небольшой части возможных проблем. Причем фрагментация и утечки памяти - наименьшие из них. В этой части достаточно одним глазком приглядывать за серваком и иметь в голове картину. Все равно она поменяется после очередного апгрейда.
Также сталкивался с проблемами, которые даже обычным рестартом плохо лечатся, т.к. контексты сеансов сохраняются. В тяжелых случаях для гарантии делаю так: рестартую, убиваю сеансы/соединения и снова рестартую.
Короче, в итоге как-то так получается, что в среднем раз в две/три недели я его руками рестартую. И это еще отличный результат, я считаю!
Да, еще всегда настраиваю, чтобы каждую базу обслуживали отдельные рабочие процессы. Так проще локализовывать и разруливать проблемы. При проблемах с конкретным рабочим процессом можно чисто его кильнуть и соседние базы это не заденет.
В идеальном мире должно работать все хорошо. Т.е. создается новый рабочий процесс, на него переползают пользовательские сессии, старый прибивается.
На практике бывают проблемы. Например, старый процесс удаляться не хочет. Это типа лечит галка его принудительного убития в этом случае. Но в рабочее время это тоже не всегда происходит без проблем для пользователей, как и поднятие новых процессов и миграция сессий. Всякое бывает. А надеяться на стабильность расписания нельзя, потому что его нет. И момент перезапуска может легко сместиться по ряду причин.
Потом, регулярный перезапуск рабочих процессов - это профилактика лишь небольшой части возможных проблем. Причем фрагментация и утечки памяти - наименьшие из них. В этой части достаточно одним глазком приглядывать за серваком и иметь в голове картину. Все равно она поменяется после очередного апгрейда.
Также сталкивался с проблемами, которые даже обычным рестартом плохо лечатся, т.к. контексты сеансов сохраняются. В тяжелых случаях для гарантии делаю так: рестартую, убиваю сеансы/соединения и снова рестартую.
Короче, в итоге как-то так получается, что в среднем раз в две/три недели я его руками рестартую. И это еще отличный результат, я считаю!
Да, еще всегда настраиваю, чтобы каждую базу обслуживали отдельные рабочие процессы. Так проще локализовывать и разруливать проблемы. При проблемах с конкретным рабочим процессом можно чисто его кильнуть и соседние базы это не заденет.
(2) herfis, а рестартуете из-за каких-то симптомов или профилактически? Насчет "Количество ИБ на процесс" я как понимаю тоже есть два мнения: "дефолт" или 1. И общая идея: если всё работает, то лучше не трогать.
А можете поделиться best practics? Хотя бы кратко и тезисно?
В этой части достаточно одним глазком приглядывать за серваком и иметь в голове картину.
А можете поделиться best practics? Хотя бы кратко и тезисно?
(3) N2, Насчет "работает - не трожь" - золотые слова. Если с дефолтовыми настройками никаких проблем не возникает, то ессно нет смысла лукаться. Сейчас вроде постабильнее, а раньше после каждого апгрейда приходилось подбирать режим, в котором относительно стабильно все работает. И да - если вам кажется, что под виндой сервер приложений имеет проблемы со стабильностью - забудьте про линукс. Там все еще хуже.
А рестартую когда как. От многих факторов и по разным причинам. Просто так складывается. Сейчас вроде тьфу-тьфу-тьфу. Если и дальше будет радовать, может и настрою авторестарт (службы) раз в неделю или две.
Что касается "приглядного" мониторинга - то все банально. Когда каждую БД обслуживают отдельные процессы, то у каждого как правило однородный характер нагрузки и потребления ресурсов. И серьезные отклонения от типичной картины несложно локализовать "вприглядку" с точностью до базы.
А рестартую когда как. От многих факторов и по разным причинам. Просто так складывается. Сейчас вроде тьфу-тьфу-тьфу. Если и дальше будет радовать, может и настрою авторестарт (службы) раз в неделю или две.
Что касается "приглядного" мониторинга - то все банально. Когда каждую БД обслуживают отдельные процессы, то у каждого как правило однородный характер нагрузки и потребления ресурсов. И серьезные отклонения от типичной картины несложно локализовать "вприглядку" с точностью до базы.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот