Проблема в следующем: 1С эпизодически притормаживает, т.е. иногда у пользователей начинает все жутко тормозить, начиная с открытия самой базы 1С, причем тормозить начинают все базы одномоментно, и также одномоментно перестают тормозить, иногда требуется перезапуск базы.
Мониторинг ресурсов показывает, что проблема скорее всего с ОЗУ на сервере 1С:Предприятия.
Скорее всего, т.к. сервер 1С:Предприятия использует всегда всю свободную оперативную память, т.е. как год назад полностью вся память использовалась, так и сейчас ничего не изменилось. Я так понимаю, подобная ситуация серверу SQL, который также если есть свободная ОЗУ он всегда найдет ей применение.
И совершенно непонятно как поймать тот момент, когда все встанет. Понятно что количество баз растет, переходим на тонкого клиента, количество пользователей растет, а когда настанет час Х совершенно непонятно.
Ситуация обострилась после перехода на программные файлы 8.3.12.1529. Причем, установили сначала на отладочный сервер, проверяли самыми различными способами около месяца, ничего не предвещало катастрофы. Обновили на рабочем сервере, а также у пользователей, пару часов поработали и сервер начал жутко тормозить, перезагрузили, пару часов и ситуация повторилась, откатились обратно.
Мониторинг ресурсов показывает, что проблема скорее всего с ОЗУ на сервере 1С:Предприятия.
Скорее всего, т.к. сервер 1С:Предприятия использует всегда всю свободную оперативную память, т.е. как год назад полностью вся память использовалась, так и сейчас ничего не изменилось. Я так понимаю, подобная ситуация серверу SQL, который также если есть свободная ОЗУ он всегда найдет ей применение.
И совершенно непонятно как поймать тот момент, когда все встанет. Понятно что количество баз растет, переходим на тонкого клиента, количество пользователей растет, а когда настанет час Х совершенно непонятно.
Ситуация обострилась после перехода на программные файлы 8.3.12.1529. Причем, установили сначала на отладочный сервер, проверяли самыми различными способами около месяца, ничего не предвещало катастрофы. Обновили на рабочем сервере, а также у пользователей, пару часов поработали и сервер начал жутко тормозить, перезагрузили, пару часов и ситуация повторилась, откатились обратно.
По теме из базы знаний
- Особенности работы сервера 1С: Предприятия и PostgreSQL для Windows, повышение быстродействия системы
- Нагрузочное тестирование сервера 1С при использовании WEB сервисов
- Учет и контроль. Механизм управления потреблением ресурсов кластера серверов 1С. Примеры использования
- Как настроить сервер 1С по умолчанию для ПРОФ лицензии после 10.09.2019
- Контроль расхода памяти сервера 1С:Предприятие 8
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)Проблема с памятью для SQL похоже проблема вечная, я для себя определил методу -
1)20 пользователей - 32 ГБ оперативки - ребут каждый месяц.
2)20 пользователей - 16ГБ оперативки - ребут каждый день.
3)40пользователей - 32ГБ оперативки - ребут раз в неделю.
Расчеты не линейны и приведены для толстого клиента.
Была ситуация - 18 пользователей 3 базы в тонком клиенте работали 6 месяцев без перезагрузки сервера 32ГБ оперативки
1)20 пользователей - 32 ГБ оперативки - ребут каждый месяц.
2)20 пользователей - 16ГБ оперативки - ребут каждый день.
3)40пользователей - 32ГБ оперативки - ребут раз в неделю.
Расчеты не линейны и приведены для толстого клиента.
Была ситуация - 18 пользователей 3 базы в тонком клиенте работали 6 месяцев без перезагрузки сервера 32ГБ оперативки
Напишите ваше сообщение
(6)Вообще SQL спокойно настраивается на потребление оперативки и ребута не требует вообще.
Да и сервер 1С так же можно настроить, но тут ребут раз в неделю ради чистки сеансовых данных и сброса рмнгр и рагента при большом количестве пользователей (100+) всё таки нужен.
(6)Вообще SQL спокойно настраивается на потребление оперативки и ребута не требует вообще.
Да и сервер 1С так же можно настроить, но тут ребут раз в неделю ради чистки сеансовых данных и сброса рмнгр и рагента при большом количестве пользователей (100+) всё таки нужен.
(9)
На вкус и цвет :-) По мне ребут по расписанию надежней - бекап + установка обновлений + регламентные задания + ребут как вишенка на тортик
Тут зависит от степени заморочки и нельзя сказать, что чей то подход не верен, привел как пользуюсь лично я.
Для примера
Напротив меня сидит сисадмин, он каждый день уже полгода что то на сервере настраивает, у меня по схеме в (6) ушло 2 дня на настройку сервера и я на него не захожу месяцами.
Вообще SQL спокойно настраивается на потребление оперативки и ребута не требует вообще
На вкус и цвет :-) По мне ребут по расписанию надежней - бекап + установка обновлений + регламентные задания + ребут как вишенка на тортик
Тут зависит от степени заморочки и нельзя сказать, что чей то подход не верен, привел как пользуюсь лично я.
Для примера
Напротив меня сидит сисадмин, он каждый день уже полгода что то на сервере настраивает, у меня по схеме в (6) ушло 2 дня на настройку сервера и я на него не захожу месяцами.
(1) Вы ничего не написали про то, настроен ли перезапуск рабочих процессов по интервалу времени.
Рабочие процессы rphost кластера 1С потребляют столько памяти, сколько им надо в данный момент. Откройте консоль администрирования, рабочие процессы - увидите что память у конкретного процесса "плавает". Другое дело что есть такое явление как утечка памяти. Для его минимизации та же 1С на ИТС рекомендует настраивать интервал перезапуска рабочих процессов в свойствах кластера. Совсем недавно зашел на один сервер, там почти 90% памяти занято, выставил перезапуск раз в сутки - теперь больше 50% почти не бывает.
Рабочие процессы rphost кластера 1С потребляют столько памяти, сколько им надо в данный момент. Откройте консоль администрирования, рабочие процессы - увидите что память у конкретного процесса "плавает". Другое дело что есть такое явление как утечка памяти. Для его минимизации та же 1С на ИТС рекомендует настраивать интервал перезапуска рабочих процессов в свойствах кластера. Совсем недавно зашел на один сервер, там почти 90% памяти занято, выставил перезапуск раз в сутки - теперь больше 50% почти не бывает.
(10)Тут только статистика именно вашей работы в 1С поможет.
Но чтобы эту статистику можно было хоть как-то аппроксимировать установите ограничение в 1-2 базы на процесс, посмотрите сколько оперативки этот процесс потребляет в пик нагрузки. Ну и дальше всё просто)
Но чтобы эту статистику можно было хоть как-то аппроксимировать установите ограничение в 1-2 базы на процесс, посмотрите сколько оперативки этот процесс потребляет в пик нагрузки. Ну и дальше всё просто)
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот