Недоступность сервера с 1С 8.2

[deinis]

Коллеги, может кто-то сталкивался с таким?
Некоторое время назад (~1мес.) обновили свою 1С 8.2. Стали современными.
С момента миграции зафиксирована уже неоднократная недоступность сервера, на котором развернуты 1С и SQL. Он просто становится недоступным. Зайти на него нельзя. Понять не можем почему. 1 или 2 раза в неделю. Лечится только перезагрузкой.

Нынешняя конфигурация:
1. Windows Server 2008 R2 EE (SP1) x64 (ранее была Windows Server 2003 x32)
2. SQL Server 2008 R2 (SP1) x64 (ранее был SQL 2005 x32)
3. 1С 8.2 x64 (ранее была 1С 8.2 x32)
4. Клиентские РМП - 1С 8.2 x32 (без изменений)
Все виртуальное (как и было), ключи - USB (как и были).
Все обновления и на 1С и на Windows ставятся своевременно.

Объем RAM 6Gb, установлено ограничение, чтобы SQL не съедал более 4Gb (Maximum server memory - 4000Mb).

[MuI_I_Ika]

Попробуйте настроить перезагрузку и лимиты для кластера.

[deinis]

Сделали настройки кластера 1С
1. Добавлен резервный рабочий процесс
2. Настроен перезапуск рабочих процессов:
- Интервал перезапуска – 86400 секунд (было 0)
- Допустимый объем памяти – 1000000 Kb (было 0)
- Интервал превышения допустимого объема памяти – 60 секунд (было 0)
- Выключенные процессы останавливать через – 125 секунд (было 0)

Настроили технологический журнал 1С. Отвели под логи 50ГБ
Настроили подробные счетчики.

Через 2 недели сервер снова стал недоступен.
Настроили еще более подробные счетчики.
Настроили автостарт счетчиков после перезапуска системы.

Сервер через какое-то время стал недоступен.
Увеличили RAM с 6ГБ до 8ГБ. Временной лаг увеличился (где-то через 2-4 недели), но в итоге сервер снова стал недоступен.

Наконец выявили рост счетчиков Memory Pool Paged Bytes и Memory Pool Non-paged Bytes через SCOM.

Стали следить за использованием памяти. Поняли, что есть утечка. Начали искать. Искали долго. Сервер пришлось несколько раз рестартовывать.

Нашли причину! В памяти оставались "хвосты" от процессов conhost.exe и cscript.exe.

Стали искать виноватых и что делать. Искали еще дольше.
Нашли!
Виновники: старые драйверы защиты аппаратного ключа (Aksdf.sys and Hardlock.sys) Stopped them and processes started terminating without being zombied.
Обновили драйверы. Зомби-процессы ушли практически полностью.

Сейчас работа стабильна (тьфу, тьфу, тьфу).
Фууу, можно выдохнуть.

[MuI_I_Ika]

Круто, а их то как раз практически никто никогда не обновляет.