← На главную

Рассмотрим распространенную и критическую ситуацию: файловая информационная база 1С:Предприятие (в данном случае отраслевое решение на базе «Бухгалтерии предприятия 2.0») расположена в общей сетевой папке на одном из рабочих компьютеров. Пока в базе находится один пользователь, система работает отзывчиво. Однако как только подключается второй оператор и начинается параллельный ввод документов (например, оформление и пробитие кассовых чеков в условиях плотного потока клиентов), база данных начинает наглухо зависать. Разберем детально технические причины такого поведения и пошагово проанализируем практические способы устранения проблемы.

Анализ причин: почему «виснет» общая папка

Для понимания вариантов оптимизации выясним первопричину зависаний на стыке операционной системы и архитектуры 1С:

1. Табличные блокировки файловой СУБД: В файловом режиме базы данных (файл с расширением .1CD) при проведении любого документа платформа накладывает блокировку на уровне целых таблиц или крупных файловых диапазонов. В конфигурациях поколения Бухгалтерии 2.0 по умолчанию действует автоматический режим блокировок. Когда один пользователь начинает транзакцию записи кассового чека, второй вынужден ожидать снятия блокировки. Через протокол сетевого доступа SMB это ожидание многократно затягивается.
2. Несовместимость сетевых протоколов SMB: Использование разных поколений операционных систем (например, Windows XP и Windows 7) приводит к деградации сетевого обмена. Windows XP поддерживает только протокол SMB 1.0, а Windows 7 по умолчанию работает с SMB 2.x. При взаимодействии таких узлов стек Windows 7 сбрасывается в режим обратной совместимости, что вызывает колоссальные сетевые задержки при обработке файловых дескрипторов.
3. Сброс кэша Oplocks (Opportunistic Locks): Сетевой механизм Oplocks пытается кэшировать части файла базы на стороне клиента. Как только второй ПК посылает запрос на запись (печать чека), хост с базой принудительно отзывает кэш у первого участника, порождая лавину блокирующих сетевых запросов и временное замирание интерфейса программы.
4. Медленные диски и аппаратные ресурсы: Классические механические накопители SATA не справляются со случайным доступом двух пользователей к одному файлу базы данных, особенно при объеме оперативной памяти в 2 ГБ, которой едва хватает для нужд самой ОС.

Решение 1. Оптимизация дисковой подсистемы и аппаратный апгрейд

Проанализируем первый и обязательный шаг: устранение аппаратного «бутылочного горлышка».

1. Перенос базы на твердотельный накопитель (SSD): Файловая база крайне чувствительна к скорости случайного чтения и записи небольших блоков данных (IOPS). Замена устаревшего диска SATA на SSD на компьютере, где физически хранится файл .1CD, сокращает время дисковых транзакций в разы.
2. Расширение оперативной памяти: 2 ГБ ОЗУ на компьютере-хосте недостаточно для буферизации файла базы и нормальной работы ОС. Рекомендуется увеличить объем оперативной памяти как минимум до 8 ГБ, чтобы дисковый кэш Windows удерживал рабочие таблицы 1С непосредственно в памяти.
3. Исключения антивирусного монитора: Защитные программы обязаны игнорировать файл базы и служебные каталоги. Добавим в список исключений антивируса расширения .1cd, .1cl, .cfl, .cdx, а также папки пользовательского кэша платформы.

Решение 2. Организация терминального режима (RDP) без задействования Windows Server

Передача блокировок файла базы данных через сеть — главная причина зависаний. Если перенести обработку базы полностью на одну физическую машину, сетевой оверхед протокола SMB полностью нивелируется.

Посмотрим, как это реализовать в рамках десктопных версий Windows:

1. Развернем терминальный доступ ко второму компьютеру с помощью специализированных сторонних решений для организации нескольких RDP-сессий на клиентских ОС (без покупки дорогостоящего Windows Server).
2. В этом случае база данных лежит локально на мощном ПК. Первый оператор работает за ним напрямую, а второй подключается удаленно через стандартный протокол удаленного рабочего стола.
3. Файл базы больше не транслируется по локальной сети: чтение, запись и наложение блокировок выполняются внутри оперативной памяти и локального контроллера диска одного компьютера. Торговое оборудование (фискальные регистраторы и принтеры чеков) пробрасываются в сеанс RDP через виртуальные COM-порты.

Решение 3. Тонкая настройка сетевых протоколов и Oplocks

Если терминальный режим временно невозможен и база должна оставаться в расшаренной папке, настроим сетевую подсистему для минимизации коллизий:

1. Выравнивание версий ОС: Избавимся от устаревшей Windows XP в пользу одинаковых версий Windows (например, Windows 7/10/11 на обеих машинах), чтобы клиенты общались по современным ревизиям протокола SMB без сваливания в режим деградации.
2. Отключение механизма Oplocks: На компьютере, на котором расшарена папка с базой данных, отключим оппортунистические блокировки через системный реестр, чтобы предотвратить непрерывный отзыв прав на кэш при одновременной записи. Для этого в ветке реестра сервера SMB создается параметр EnableOpLocks = 0.
3. Настройка сетевых плат: В свойствах сетевого адаптера на обеих машинах отключим функции разгрузки TCP (Large Send Offload / LSO) и режимы энергосбережения сетевого чипа (Green Ethernet), провоцирующие задержки мелких синхронизирующих пакетов блокировок 1С.

Решение 4. Использование механизма Распределенных Информационных Баз (РИБ)

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

1. Настроим стандартный функционал планов обмена 1С:Предприятие и создадим периферийную базу данных для второго рабочего места.
2. Каждый кассир работает со своей локальной копией базы данных на максимальной скорости диска, не ожидая завершения транзакций соседа. Чеки пробиваются мгновенно, так как между машинами отсутствует постоянная транзакционная зависимость.
3. Синхронизация данных между центральной и периферийной базой настраивается по удобному расписанию (например, каждые 15–30 минут или в конце рабочей смены), что полностью снимает проблему зависания интерфейса в пиковые часы обслуживания клиентов.

Почему установка сервера 1С и PostgreSQL на слабую рабочую станцию не поможет?

Часто в подобных ситуациях предлагают поднять связку Сервер 1С:Предприятия + PostgreSQL прямо на компьютере с Windows XP. Разберем, почему этот путь тупиковый: клиентская 32-разрядная система Windows XP накладывает лимит в 2 ГБ адресного пространства на процесс, имеет жесткие системные ограничения по количеству сетевых сокетов и примитивный планировщик ввода-вывода. Полноценная СУБД вместе со службами сервера 1С мгновенно исчерпает оперативную память объемом 2 ГБ, вызвав непрерывный свопинг на жесткий диск и падение рабочих процессов при первом же обращении пользователей.