Как устранить зависание пользователей 1С при работе с файловой базой через IIS?

Работа в 1С через веб-сервер IIS в файловом режиме — это популярное решение для небольших компаний, которое позволяет избежать затрат на серверную лицензию 1С и MS SQL Server. Однако часто системные администраторы сталкиваются с критической проблемой: как только один пользователь запускает «тяжелый» отчет или ресурсоемкую обработку, работа всех остальных веб-пользователей полностью парализуется. В это время новые подключения невозможны, а у активных сессий «вращается колесико» до тех пор, пока отчет не будет сформирован. При этом пользователи, подключенные через локальную сеть (по протоколу SMB), продолжают работать без проблем.

В этой статье мы подробно разберем, почему возникает такая ситуация, проанализируем механизмы блокировок и рассмотрим практические способы решения проблемы, включая настройку нескольких независимых публикаций.

Выясним причину: почему файловая база «зависает» на веб-сервере

Проанализируем архитектуру взаимодействия веб-сервера и 1С. Когда вы публикуете базу на IIS, используется расширение веб-сервера — библиотека wsisapi.dll. В случае с файловой базой (файл 1Cv8.1CD) возникают следующие ограничения:

1. Однопоточность доступа к ядру: Расширение веб-сервера для файлового варианта фактически работает в режиме очереди. Когда выполняется длительный запрос к данным, ядро 1С блокирует таблицу или всю базу целиком для обеспечения целостности. Остальные HTTP-запросы становятся в очередь пула приложений IIS.
2. Ограничения операционной системы: Если веб-сервер развернут на клиентской ОС (например, Windows 10), в ней действуют жесткие лимиты на количество одновременных входящих TCP-соединений. Очередь запросов быстро переполняется, и IIS перестает выдавать даже окно авторизации.
3. Блокировки на уровне файлов: Файловая база использует механизмы блокировок операционной системы. При интенсивном чтении/записи через веб-сервер возникают конфликты доступа к файлу 1Cv8.clck, который отвечает за управление сеансами.

Рассмотрим подробнее решения, которые помогут обойти эти ограничения без перехода на полноценный клиент-серверный вариант.

Решение 1: Создание независимых публикаций для каждого пользователя

Наиболее действенный, хотя и трудоемкий «костыль» — это разнесение пользователей по разным портам и процессам IIS. Это позволяет создать для каждого (или для групп пользователей) свой собственный рабочий процесс, который будет иметь отдельную очередь запросов. Разберем этот процесс по шагам.

Шаг 1. Подготовка основной публикации

Сначала убедимся, что у нас есть базовая рабочая публикация, созданная через конфигуратор или утилиту webinst. Допустим, она называется buh и находится по пути C:\inetpub\wwwroot\buh. Проверьте, что файл default.vrd настроен корректно.

Шаг 2. Настройка дополнительных сайтов в IIS

Для создания дополнительных точек входа выполним следующие действия:

1. Откроем Диспетчер служб IIS.
2. Нажмем правой кнопкой мыши на узел «Сайты» и выберем «Добавить веб-сайт».
3. Укажем имя сайта, например, 1C_User1.
4. Создадим отдельную физическую папку для этого сайта, например C:\inetpub\www_user1.
5. Назначим уникальный порт (например, 90).

Шаг 3. Копирование и преобразование в приложение

1. Скопируем содержимое папки оригинальной публикации buh в новую папку C:\inetpub\www_user1.
2. В диспетчере IIS обновим дерево сайтов (F5).
3. Внутри нового сайта 1C_User1 найдем скопированную папку buh, нажмем на нее правой кнопкой мыши и выберем «Преобразовать в приложение».

Теперь пользователь может подключаться по адресу http://имя_сервера:90/buh. Повторите эти шаги для других портов (91, 92 и т.д.). Поскольку каждый сайт в IIS работает в своем пуле приложений, «зависание» процесса на порту 80 не заблокирует работу процесса на порту 90. Не забудьте открыть соответствующие порты в брандмауэре Windows.

Решение 2: Переход на Автономный сервер (ibsrv.exe)

Начиная с версии платформы 8.3.14, компания 1С представила новый инструмент — Автономный сервер. Это решение специально создано для эффективной работы с файловыми базами через HTTP без использования тяжеловесных IIS или Apache.

Проанализируем преимущества автономного сервера:

• Он более эффективно управляет очередью запросов к файловой базе.
• Он меньше зависит от настроек окружения ОС.
• Его проще масштабировать.

Для запуска автономного сервера используется командная строка. Рассмотрим пример команды для запуска:

ibsrv.exe --db-path="C:\1C_Bases\Accounting" --port=8080 --daemon

Если вам требуется поддержка протокола HTTPS, рекомендуется использовать схему Reverse Proxy. В этом случае IIS или Nginx принимает входящий защищенный трафик и перенаправляет его локально на порт автономного сервера. Это избавляет от необходимости «мучать» IIS прямыми публикациями файловых баз.

Решение 3: Оптимизация параметров публикации и фоновых заданий

Иногда проблему можно смягчить тонкой настройкой конфигурационного файла публикации default.vrd. Разберем ключевые параметры:

1. Параметр pooling: По умолчанию он может быть выключен. Попробуем включить пул соединений, чтобы ускорить повторные подключения, однако для файловой базы это нужно делать осторожно.
2. Фоновые задания: В файловой базе при работе через веб фоновые задания выполняются в том же сеансе. Если база «висит», фоновые задания (например, загрузка курсов валют или классификаторов) только усугубляют ситуацию.

Рекомендуется программно отключать выполнение ресурсоемких регламентных заданий в рабочее время. Для этого можно использовать следующий фрагмент кода в модуле управляемого приложения или через консоль заданий:

// Пример отключения регламентного задания
Задание = РегламентныеЗадания.НайтиПоНаименованию("ОбновлениеИндексаПолнотекстовогоПоиска");
Если Задание <> Неопределено Тогда
    Задание.Использование = Ложь;
    Задание.Записать();
КонецЕсли;

Рекомендации по настройке пулов приложений в IIS

Если мы продолжаем использовать IIS, важно правильно настроить «Пул приложений» (Application Pool), в котором работает 1С. Посмотрим на критически важные настройки:

• Максимум рабочих процессов (Web Garden): В настройках пула приложений можно увеличить значение этого параметра (по умолчанию 1). Для файловой базы это спорное решение, но установка значения 2 или 3 иногда позволяет «проскочить» легким запросам, пока один процесс занят тяжелым отчетом.
• Тайм-аут простоя (Idle Time-out): Установите его в значение 0, чтобы IIS не тратил ресурсы на постоянный перезапуск процесса.
• Длина очереди (Queue Length): Увеличьте это значение (например, до 5000), чтобы пользователи реже видели ошибку 503 Service Unavailable при пиковых нагрузках.

Итоги и выбор стратегии

Подводя итог, можно сказать, что «зависание» — это врожденная особенность файлового режима. Если бюджет позволяет, переход на клиент-серверный вариант (SQL) решит проблему раз и навсегда за счет гранулярных блокировок (на уровне записи, а не таблицы).

Если же нужно остаться в рамках файловой базы, наиболее надежным современным методом является использование Автономного сервера 1С. Метод с созданием множества сайтов на разных портах в IIS (Solution 1) остается рабочим «спасательным кругом» для тех, кто по каким-то причинам привязан к старым версиям платформы или специфическим настройкам IIS.