При организации многопользовательской работы с файловой информационной базой «1С:Предприятие 8.3» на управляемых формах нередко возникает ситуация, когда при одновременном подключении локальных пользователей через общий сетевой ресурс и удаленных пользователей через веб-сервер база начинает регулярно зависать. При этом сеансы клиентов, аварийно снятые через диспетчер задач, остаются заблокированными на сервере, препятствуя выполнению регламентных процедур и созданию резервных копий. Рассмотрим детально причины такого поведения платформы и разберем по шагам практические способы стабилизации работы и управления сеансами.
Причины конфликтов и зависаний при смешанном доступе
Проанализируем архитектуру файлового режима. Вся информационная база хранится в едином файле 1Cv8.1CD. Когда пользователи работают в смешанном режиме, происходят следующие конфликты:
Разделение файловых блокировок: Пользователи из локальной сети обращаются к файлу напрямую через протокол SMB (общую сетевую папку Windows), накладывая на файл базы низкоуровневые блокировки операционной системы. Веб-сервер (Apache или IIS) также обращается к этому файлу локально от имени своего сервисного процесса. Возникает конфликт очередей блокировок между сетевым стеком SMB и локальным процессом веб-сервера, что приводит к состоянию взаимоблокировки (Deadlock).
Отсутствие версионности транзакций: В файловом хранилище нет полноценного механизма MVCC (многоверсионного управления параллельным доступом), свойственного промышленным СУБД. Выполнение тяжелого отчета (например, оборотно-сальдовой ведомости или карточки счета за большой период) монопольно захватывает целые таблицы базы данных. В этот момент короткие веб-запросы других пользователей выстраиваются в очередь ожидания, завершаются по сетевому тайм-ауту и приводят к аварийному вылету тонких клиентов.
Потеря соединения и зависшие дескрипторы: Если удаленный тонкий клиент разрывает соединение или пользователь принудительно «убивает» процесс на клиентском ПК, рабочий процесс веб-сервера не всегда мгновенно освобождает дескрипторы файла базы данных, удерживая блокировку на стороне сервера.
Перевод всех пользователей на единый канал через веб-сервер
Разберем главное правило стабильной работы файловой базы с числом пользователей более 5–10: нельзя сочетать прямой доступ по локальной сети и доступ через веб-сервер. Все клиентские машины — как удаленные филиалы, так и компьютеры в офисной локальной сети — должны подключаться исключительно через веб-сервер.
Для перевода локальных рабочих мест выполним следующие действия:
Закроем общий сетевой доступ (Share) к каталогу с базой данных на сервере. Это исключит прямой доступ к файлу 1Cv8.1CD и дополнительно защитит базу от вирусов-шифровальщиков, которые поражают только общедоступные сетевые папки.
В списке баз на локальных компьютерах изменим строку подключения. Вместо пути к каталогу (вида File="\\server\base") укажем веб-адрес публикации (вида ws="http://server/base").
На компьютерах пользователей останется установленным полноценный тонкий клиент 1С, обеспечивающий привычный интерфейс, стабильную печать и корректную работу торгового оборудования, но передача данных пойдет по HTTP/HTTPS.
При такой схеме с файлом базы взаимодействует ровно один механизм — модуль веб-расширения 1С, что сводит возникновение файловых конфликтов к минимуму.
Выбор веб-сервера: Apache или Microsoft IIS
Практический опыт эксплуатации файловых конфигураций показывает, что выбор веб-сервера напрямую влияет на стабильность:
Apache HTTP Server: Часто используется в версиях 2.2 и 2.4 благодаря простоте первичного развертывания. Однако при интенсивной нагрузке и параллельных запросах модуль 1С под Apache на платформе Windows может демонстрировать утечки дескрипторов и нестабильность рабочих потоков.
Internet Information Services (IIS): Демонстрирует значительно более высокую отказоустойчивость при работе с файловыми базами 1С в среде Windows. IIS лучше управляет пулами приложений, потоками и переработкой памяти.
При настройке публикации на веб-сервере IIS крайне важно соблюдать ключевое системное ограничение:
Откроем консоль управления IIS (Диспетчер служб IIS).
Перейдем в раздел Пулы приложений и откроем «Дополнительные параметры» для пула, обслуживающего базу 1С.
Параметр Максимальное число рабочих процессов (Maximum Worker Processes) обязательно установим равным 1 (режим Web Garden категорически запрещен для файловых баз 1С, так как несколько процессов w3wp.exe при одновременном обращении к одному файлу 1Cv8.1CD разрушают структуру данных).
Параметр Тайм-аут простоя (в минутах) (Idle Time-out) установим в значение 0, чтобы процесс не выгружался из памяти при временном отсутствии обращений.
Способы принудительного завершения зависших сеансов
Выясним, как завершать зависшие сеансы без перезагрузки сервера и без необходимости запуска процесса обновления конфигурации.
Перезапуск службы или пула веб-сервера: Поскольку все пользователи работают через веб-сервер, для мгновенного сброса всех зависших веб-сеансов достаточно выполнить перезапуск пула приложений или самой службы.
Для IIS достаточно выполнить команду сброса пула без прерывания работы других сайтов:
Для Apache достаточно выполнить перезапуск службы операционной системы через командную строку:
net stop Apache2.4
net start Apache2.4
Это действие немедленно высвобождает файл базы данных из захвата процессом веб-сервера.
Штатная блокировка соединений: В типовых конфигурациях (включая «1С:Бухгалтерию») присутствует подсистема «Блокировка работы пользователей». Ее можно активировать через меню «Администрирование» — «Обслуживание» — «Блокировка работы пользователей». Данный механизм рассылает сигнал завершения сеансов через фоновый обработчик ожидания. Однако если сеанс клиента намертво завис в цикле или системной блокировке, он не сможет отреагировать на сигнал, и потребуется применение серверного перезапуска, описанного выше.
Сброс зависших дескрипторов на уровне Windows: Если файл базы удерживается локальным пользователем или службой, можно принудительно закрыть файловые дескрипторы через оснастку «Управление компьютером» — «Общие папки» — «Открытые файлы» либо с помощью системной команды openfiles /disconnect.
Организация работы с аппаратными ключами защиты HASP
При использовании веб-сервера часто возникает сложность с распределением лицензий: сервер видит только ключ, установленный локально, либо возникает конфликт двух одинаковых сетевых ключей (например, двух ключей на 10 пользователей серии ORGL8). Рассмотрим, как решить эту проблему без затрат на объединение ключей:
Два сетевых ключа одинаковой серии нельзя устанавливать в один системный блок, так как служба HASP License Manager будет обслуживать только один из них. Установим второй ключ на любой другой постоянно включенный компьютер в локальной сети и запустим на нем отдельную службу лицензий.
В файле конфигурации менеджера лицензий nhsrv.ini на каждой машине укажем уникальные имена серверов в параметре NHS_SERVERNAMES.
На машине с веб-сервером отредактируем файл nethasp.ini (расположенный в папке bin\conf платформы 1С). Отключим широковещательный поиск и перечислим IP-адреса обоих компьютеров с ключами:
После этого веб-сервер сможет последовательно опрашивать оба менеджера лицензий и раздавать клиентам до 20 лицензий суммарно.
Итоги и рекомендации
Перевод всех рабочих мест на единый доступ через тонкий клиент веб-сервера позволяет стабилизировать файловую базу 1С и исключить взаимные блокировки файлов. Тем не менее следует учитывать, что при регулярном формировании тяжелых отчетов файловая архитектура неизбежно будет снижать отзывчивость для остальных участников. Окончательным решением для коллектива от 10–15 активных пользователей является переход на клиент-серверный вариант (с использованием сервера 1С:Предприятия и бесплатной СУБД PostgreSQL), где блокировки строк и версионность транзакций полностью изолируют читающие операции от пишущих.