Проблема в следующем: 1С эпизодически притормаживает, т.е. иногда у пользователей начинает все жутко тормозить, начиная с открытия самой базы 1С, причем тормозить начинают все базы одномоментно, и также одномоментно перестают тормозить, иногда требуется перезапуск базы.
Мониторинг ресурсов показывает, что проблема скорее всего с ОЗУ на сервере 1С:Предприятия.
Скорее всего, т.к. сервер 1С:Предприятия использует всегда всю свободную оперативную память, т.е. как год назад полностью вся память использовалась, так и сейчас ничего не изменилось. Я так понимаю, подобная ситуация серверу SQL, который также если есть свободная ОЗУ он всегда найдет ей применение.
И совершенно непонятно как поймать тот момент, когда все встанет. Понятно что количество баз растет, переходим на тонкого клиента, количество пользователей растет, а когда настанет час Х совершенно непонятно.
Ситуация обострилась после перехода на программные файлы 8.3.12.1529. Причем, установили сначала на отладочный сервер, проверяли самыми различными способами около месяца, ничего не предвещало катастрофы. Обновили на рабочем сервере, а также у пользователей, пару часов поработали и сервер начал жутко тормозить, перезагрузили, пару часов и ситуация повторилась, откатились обратно.
3.
a.doroshkevich
151322.08.18 12:04 Сейчас в теме
(1)3.12 и 3.13 стали потреблять в разы больше памяти (это баг, должны поправить)
Я бы пока для стабилизирования ситуации настроил ограничение по памяти для процессов 1С и ограничение кол-ва баз на процесс
Это должно избавить от торможения всего сразу
(1)Проблема с памятью для SQL похоже проблема вечная, я для себя определил методу -
1)20 пользователей - 32 ГБ оперативки - ребут каждый месяц.
2)20 пользователей - 16ГБ оперативки - ребут каждый день.
3)40пользователей - 32ГБ оперативки - ребут раз в неделю.
Расчеты не линейны и приведены для толстого клиента.
Была ситуация - 18 пользователей 3 базы в тонком клиенте работали 6 месяцев без перезагрузки сервера 32ГБ оперативки
9.
a.doroshkevich
151322.08.18 15:19 Сейчас в теме
Напишите ваше сообщение
(6)Вообще SQL спокойно настраивается на потребление оперативки и ребута не требует вообще.
Да и сервер 1С так же можно настроить, но тут ребут раз в неделю ради чистки сеансовых данных и сброса рмнгр и рагента при большом количестве пользователей (100+) всё таки нужен.
Вообще SQL спокойно настраивается на потребление оперативки и ребута не требует вообще
На вкус и цвет :-) По мне ребут по расписанию надежней - бекап + установка обновлений + регламентные задания + ребут как вишенка на тортик
Тут зависит от степени заморочки и нельзя сказать, что чей то подход не верен, привел как пользуюсь лично я.
Для примера
Напротив меня сидит сисадмин, он каждый день уже полгода что то на сервере настраивает, у меня по схеме в (6) ушло 2 дня на настройку сервера и я на него не захожу месяцами.
(1) Вы ничего не написали про то, настроен ли перезапуск рабочих процессов по интервалу времени.
Рабочие процессы rphost кластера 1С потребляют столько памяти, сколько им надо в данный момент. Откройте консоль администрирования, рабочие процессы - увидите что память у конкретного процесса "плавает". Другое дело что есть такое явление как утечка памяти. Для его минимизации та же 1С на ИТС рекомендует настраивать интервал перезапуска рабочих процессов в свойствах кластера. Совсем недавно зашел на один сервер, там почти 90% памяти занято, выставил перезапуск раз в сутки - теперь больше 50% почти не бывает.
Настройте счетчики на используемые ресурсы. Вы ж не знаете что у вас на сервере происходит.
Проверьте утечки памяти: https://kb.1c.ru/articleView.jsp?id=85 Настройте ЦКК
(5) Интересная статья, но это не наш случай. У нас по объективной причине, а конкретно рост количества баз, закончились ресурсы на сервере.
Проблема в другом, непонятно как оценить сколько памяти хватит серверу для нормальной работы.
11.
a.doroshkevich
151322.08.18 15:42 Сейчас в теме
(10)Тут только статистика именно вашей работы в 1С поможет.
Но чтобы эту статистику можно было хоть как-то аппроксимировать установите ограничение в 1-2 базы на процесс, посмотрите сколько оперативки этот процесс потребляет в пик нагрузки. Ну и дальше всё просто)