При активной работе с веб- и HTTP-сервисами в 1С системные администраторы и разработчики часто сталкиваются с проблемой: в консоли администрирования кластера зависают сеансы с типом соединения «модуль расширения веб-сервера» (или «модуль расширения веб-сервиса»). Попытка завершить их вручную через консоль ни к чему не приводит — сеансы либо вообще не удаляются, либо мгновенно появляются снова. При этом внешние системы начинают получать ошибку «Истекло время ожидания сеанса» (часто сопровождающуюся HTTP-статусом 406).
В этой статье мы подробно разберем, почему возникает эта проблема, как устроена механика работы веб-сервисов в 1С и какими способами можно восстановить работоспособность системы без полной перезагрузки всего сервера. Для оперативного завершения зависших сессий и рабочих процессов можно воспользоваться веб-приложением для управления сеансами сервера 1С.
Начиная с версии платформы 1С:Предприятие 8.3.9, по умолчанию задействован механизм повторного использования сеансов (session pooling). Это архитектурное решение создано для оптимизации производительности: вместо того чтобы создавать и инициализировать тяжелый сеанс 1С под каждый отдельный HTTP- или SOAP-запрос, платформа держит пул уже готовых («спящих») сеансов. В консоли кластера они отображаются как раз как «модули расширения веб-сервера».
Когда внешняя система присылает запрос, веб-сервер (IIS или Apache) мгновенно выделяет под него сеанс из этого пула. Если все сеансы в пуле оказываются заняты (например, из-за длительного выполнения тяжелых экспортных запросов, взаимоблокировок в СУБД или бесконечных циклов в коде), новые запросы встают в очередь ожидания. Если время нахождения запроса в очереди превышает установленный лимит, платформа возвращает клиенту ошибку «Истекло время ожидания сеанса».
Попытка удалить такое соединение вручную бесполезна: веб-сервер жестко удерживает открытый пул соединений и принудительно пересоздает сеансы при попытке их закрытия со стороны кластера 1С, либо в этот момент продолжает идти непрерывный поток запросов.
Рассмотрим пошагово рабочие методы устранения этой проблемы.
Если ваши HTTP-сервисы вызываются не слишком часто (например, несколько раз в минуту) или если стабильность для вас критичнее микросекундных задержек на авторизацию сеанса, пул сеансов можно отключить. Для этого выполним следующие действия:
C:\inetpub\wwwroot\ИмяБазы, для Apache путь указывается в конфигурационном файле httpd.conf).default.vrd любым текстовым редактором.<httpService> или <webService>.reuseSessions, установив для него значение "dontuse".Пример корректной настройки в файле default.vrd:
<httpService name="Exchange"
alias="exchange"
enable="true"
reuseSessions="dontuse" />
После сохранения файла веб-сервер автоматически применит настройки. Теперь под каждый входящий запрос будет создаваться индивидуальный кратковременный сеанс, который гарантированно уничтожится сразу после отдачи ответа клиенту. Это полностью исключит зависание пула.
Если пул сеансов вам все-таки необходим, мы можем ограничить его аппетиты с помощью параметров poolSize (максимальное количество удерживаемых сеансов) и poolTimeout (время жизни неактивного сеанса в пуле в секундах):
<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="Server1C";Ref="MyBase";">
<ws>
<pool size="10" timeout="60" />
</ws>
</point>
Этот способ идеально подходит для Windows-серверов под управлением IIS. По умолчанию все публикации баз 1С работают в рамках одного общего пула приложений — DefaultAppPool. Если зависает одна база или один некорректный сервис, администраторам приходится перезапускать весь веб-сервер IIS, что прерывает работу пользователей во всех остальных базах.
Проанализируем, как изолировать базы друг от друга:
1C_Exchange_Pool.1C_Exchange_Pool.Теперь, если сеансы веб-сервиса снова зависнут, нам не нужно перезагружать весь сервер. Достаточно зайти в Диспетчер IIS, выбрать наш пул приложений 1C_Exchange_Pool и нажать кнопку «Рециркуляция» (Recycle) или «Перезапуск». Это мгновенно и абсолютно безопасно завершит рабочий процесс w3wp.exe, обслуживающий только эту конкретную базу, очистив все зависшие модули расширения 1С без прерывания работы других сервисов и пользователей.
Мы можем настроить автоматическое завершение «спящих» сеансов на стороне самого кластера 1С. Для этого необходимо зайти в свойства информационной базы через Конфигуратор или консоль администрирования кластера и скорректировать следующие параметры:
Если ваша информационная база развернута в файловом режиме, стандартная консоль кластера 1С недоступна. При зависании процессов веб-сервер может намертво заблокировать файлы базы данных (1Cv8.1CD).
В этом случае для быстрой очистки зависших сеансов нам потребуется принудительно завершить рабочие процессы операционной системы. Выполним команду в командной строке (cmd) от имени администратора:
taskkill /IM 1cv8.exe /F
Важная рекомендация для IIS в файловом режиме: зайдите в дополнительные параметры пула приложений IIS, обслуживающего файловую базу 1С, и установите значение параметра «Максимальное количество рабочих процессов» равным 1. Если там будет стоять значение больше единицы, параллельные процессы IIS начнут конфликтовать за доступ к файлу базы данных, что приведет к регулярным зависаниям модулей расширения.
Регулярные зависания пула сеансов — это почти всегда следствие проблем в программном коде вашего HTTP- или Web-сервиса. Это может быть незакрытая транзакция, бесконечный цикл или слишком долгий запрос к СУБД.
Для детальной диагностики настроим сбор Технологического журнала 1С. Создадим файл конфигурации logcfg.xml в каталоге C:\Program Files\1cv8\conf со следующим содержимым:
<config xmlns="http://v8.1c.ru/v8/tech-journal">
<log location="C:\1C_Logs\VRS" history="24">
<event>
<eq property="Name" value="VRSREQUEST"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
Этот лог позволит нам отследить событие VRSREQUEST (запросы к веб-сервисам) и сопоставить время начала выполнения запроса с моментами зависания процессов. Если в логах также будут зафиксированы события EXCP (исключительные ситуации), мы сможем точно локализовать проблемную строчку кода в общем модуле 1С.
Когда вы применили настройки и хотите убедиться, что зависания прекратились, а сервис отвечает корректно, отправлять POST- или GET-запросы напрямую из кода 1С или писать для этого сложные HTML-страницы с JavaScript-скриптами не совсем удобно. Для быстрой и наглядной отладки веб-сервисов рекомендуется использовать специализированные инструменты тестирования API:
Использование этих инструментов совместно с грамотно настроенным пулом приложений веб-сервера позволит вам раз и навсегда забыть о зависших сеансах и обеспечит стабильную интеграцию 1С с любыми внешними системами. Для проверки и отладки запросов непосредственно в среде 1С можно использовать обработку для тестирования REST API на платформе 1С.