Ситуация, когда количество соединений с базой данных MSSQL начинает кратно превышать количество активных пользователей, является классической проблемой при использовании тонкого клиента через веб-сервер (IIS или Apache). В нормальных условиях на одного пользователя приходится 1–1.5 соединения, но в моменты сбоев это число может вырастать до 5 и более. Это приводит к деградации производительности, «подвисанию» консоли администрирования 1С и жалобам пользователей на «тупизну» системы. Рассмотрим подробно, почему это происходит и как стабилизировать работу сервера.
Когда пользователи подключаются к 1С через веб-публикацию, между клиентским приложением и SQL-сервером появляется посредник — модуль расширения веб-сервера. В консоли кластера 1С такие соединения помечаются соответствующей строкой. Особенность заключается в том, что веб-сервер использует пул соединений. Это механизм, при котором соединения с СУБД не разрываются сразу после завершения запроса пользователя, а сохраняются «про запас», чтобы следующий запрос не тратил время на установку новой сессии с SQL.
Проблема возникает, когда этот пул начинает бесконтрольно раздуваться. Выясним основные причины этого поведения:
Первым делом разберем настройки самой информационной базы. Часто стандартные значения не подходят для высоконагруженных систем. Перейдем в раздел Администрирование — Параметры информационной базы (в режиме «1С:Предприятие») или в свойства базы в консоли администрирования кластера.
Обратим внимание на следующие параметры:
300–600 секунд (5–10 минут).1200–1800 секунд (20–30 минут).Если эти значения слишком велики (например, по умолчанию может стоять час или более), сервер будет копить «мертвые» соединения от пользователей, которые просто закрыли ноутбук или ушли на обед, не выйдя из системы.
Файл default.vrd находится в каталоге публикации на веб-сервере (обычно это C:\inetpub\wwwroot\ИмяВашейБазы\). Именно в нем хранятся настройки взаимодействия модуля 1С с пулом соединений. Разберем, какие параметры нужно добавить или изменить внутри тега <point>.
Найдем или создадим секцию настроек пула. Пример структуры кода в default.vrd:
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/MyBase"
ib="Srvr="MyServer";Ref="MyBase";">
<httpServices>
<service name="Mobile" rootUrl="mobile" enable="true" reuseSessions="autouse"/>
</httpServices>
<standardOdata enable="false" reuseSessions="autouse" />
<pool size="10" timeout="60" lastAge="120" />
</point>
Проанализируем атрибуты тега pool:
size: Максимальное количество соединений в пуле для одного рабочего процесса веб-сервера. Ограничение этого параметра не дает «забить» SQL-сервер бесконечными подключениями.timeout: Время (в секундах), в течение которого соединение в пуле считается валидным для повторного использования.lastAge: Максимальное время жизни соединения. После этого срока соединение будет принудительно закрыто и создано новое. Это помогает бороться с «утечками» соединений.
Важно: После внесения изменений в default.vrd необходимо выполнить команду iisreset в командной строке от имени администратора, чтобы настройки вступили в силу.
Ситуация, когда «консоль виснет намертво», часто указывает на то, что рабочий процесс IIS (w3wp.exe) потребляет слишком много ресурсов или блокирует потоки. Посмотрим на настройки Application Pool (Пула приложений), в котором работает ваша публикация.
Рассмотрим ключевые настройки в диспетчере служб IIS:
0 (бесконечность).Если мы видим рост соединений, нам нужно понять, что они делают. Выясним это с помощью системного представления MSSQL. Выполним следующий запрос в SQL Management Studio:
SELECT
des.session_id,
des.status,
des.last_request_start_time,
des.last_request_end_time,
des.program_name,
dec.client_net_address
FROM sys.dm_exec_sessions AS des
JOIN sys.dm_exec_connections AS dec ON des.session_id = dec.session_id
WHERE des.program_name LIKE '%1C%'
ORDER BY des.last_request_start_time DESC;
Проанализируем результат. Если мы видим множество сессий со статусом sleeping и временем last_request_end_time, которое было более 15–20 минут назад, значит, механизм очистки пула на стороне 1С или веб-сервера не срабатывает. Это прямое подтверждение того, что нужно уменьшать параметры poolTimeout в default.vrd или время завершения спящих сеансов в 1С.
Поскольку пользователи работают удаленно по всей стране, критическим фактором становится стабильность TCP-сессий. При микроразрывах связи тонкий клиент «отваливается», но сервер 1С об этом узнает не сразу. Соединение с SQL остается висеть в статусе ESTABLISHED.
Для решения этой проблемы на уровне операционной системы сервера можно сократить интервалы проверки «живучести» TCP-пакетов. Это делается в реестре Windows по адресу: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. Рассмотрим параметры (их может потребоваться создать вручную типа DWORD):
KeepAliveTime: установите значение 300000 (5 минут в миллисекундах).KeepAliveInterval: установите значение 1000 (1 секунда).Это заставит ОС быстрее закрывать «брошенные» сокеты, что в свою очередь позволит кластеру 1С быстрее корректно завершать сеансы и освобождать SQL-соединения.
Подведем итог. Резкий рост соединений — это почти всегда следствие того, что новые соединения создаются быстрее, чем старые успевают закрываться по тайм-ауту.
Для стабилизации системы рекомендуем выполнить следующие действия:
default.vrd (параметр pool size).Следуя этим шагам, мы минимизируем избыточную нагрузку на СУБД и обеспечим стабильную работу пользователей даже при нестабильных каналах связи.