Как решить проблему с долгим подключение к базам 8.3 (при рабочих базах 8.2)?
Техническая часть (первоначальная):
1) 1с кластер.
ОС - 2к8 r2 (VM)
4 гб ОЗУ 2 ядра
используется только как кластер 1с и выдача лицензий
2) sql 2008 (VM)
ОС - 2r8 r2
16 гб ОЗУ 4 ядра
используется только под SQL
3) sql 2008 (VM)
ОС - 2k8 r2
12 гб ОЗУ 4 ядра
используется только под SQL
Физика:
1,2 VM лежат в кластер 2k8 r2 состоящий из 2-ух нод
e5645 (2 шт) и 64 гб hp360g7 + sas iscsi hp p2000g3
3 VM лежит в standaline 2k8 r2
e5-2690 (2шт) и 64 гб hp360g8
Сеть: Cisco 2960g (1 подсеть) - 1гб
Планируется переход на версию 8.3, поэтому на данный момент работают две платформу 8.2.19.83 и 8.3.5.1486. (ключ 64 битный)
7 баз 8.2 с кол-во пол-ей не более 30 (sql1)
5 баз 8.3 с кол-по пол-ей от 1-2 (sql2)
Имеем хаотические проблемы связанные с кластером 8.3 , периодически очень долго запускаются базы 8.3 ( от 30 -5 минут)
и вылетают пол-и из за нехватки памяти.
Были проделаны работы:
а) Оптимизация работа по памяти кластера 8.3
параметры кластера:
Интервал перезапуска:86400
Интервал превышения допустимого объема памяти:30
Включенные процессы останавливать через:30
Приоритет по памяти
параметры рабочего сервера:
Безопасный расход памяти 512мб
Объем памяти рабочих процессов, до которого сервер считается проивод 700 мб
Кол-во ИБ на процесс: 1
Кол-во соединений на процесс 25
Решило проблему с вылетами
2) Перенастройка клиентов на поиск лицензии со стороны сервера с исправлением файла на сервере nethasp.ini
NH_SERVER_ADDR = 192.168.112.18
NH_USE_BROADCAST = Disabled
В данном случаи у нас 30 лицензий программных и ключ на 10 на 18 сервере.
3) После старта службы агента 8.3 в логах зафиксирована проблема:
Сбойное приложение ragent.exe, версия 8.3.5.1486, штамп времени 0x54f76689, сбойный модуль rtrsrvc.dll, версия 8.3.5.1486, штамп времени 0x54f7685d, код исключения 0xc0000005, смещение ошибки 0x00000000000020f4, ИД процесса 0xcb4, время запуска приложения 0x01d065fa56ec19bd.
4) Была попытка переставить платформу (8.3) с нуля, но ошибка осталась.
5) Было принято решение совместить базы с первым скулем.
6) Технический журнал 1с отдан по ИТС поддержке, ошибок не обнаружено.
На данный момент все ВМ лежат к кластере Hyper-V. Из предполаемых решений только 2:
а) Разнести службы на разных пользователей
6) Сменить диапазон портов на 8.3 службе
в) Поднять 2012 r2 (запланирован переход инфраструктуры под hyper-v 3.0) и установить скуль внутрь машины, посмотреть что будет.
Когда кластер 1c функционировал только как 1с 8.2, объем памяти был равен - 2 гб с 1 ядром. И никаких проблем с производительностью никогда не было. Поэтому увеличение ОЗУ до 4 гб и ядер до 2- ух, обусловлено тем, что базы работают в тестовом режиме. Учитывая что все транзакции у нас обрабатывает скуль а запросы делает пользователь как толстый клиент. Выставлять большее значение я на тот момент не видел смысла. При чем проблемы зафиксированы в основном утром, неважно один человек заходит или 4 сразу. В середине дня проблем не зафиксировано.
