← На главную

При организации розничной точки с двумя рабочими местами часто выбирают простую архитектуру: на первой кассе размещается локальная файловая база, а вторая касса подключается к ней через общую сетевую папку Windows (протокол SMB). Однако при росте объема данных (например, справочника физических лиц до 200 000–250 000 записей) система сталкивается с катастрофической деградацией: локально запрос выполняется за 4 секунды, а со второго компьютера тот же запрос длится более 7 минут. При этом сам файл 1Cv8.1CD может неконтролируемо раздуваться с 3,5 ГБ до 16 ГБ.

Проанализируем технические причины такого поведения файловой СУБД 1С и разберем практические способы решения проблемы без дорогостоящей покупки сервера «1С:Предприятия».

Почему файловая 1С тормозит и раздувается при сетевом доступе через общую папку?

Выясним причину многократного падения скорости. В файловом режиме вся логика СУБД выполняется непосредственно на стороне запущенного клиента (процесса 1cv8c.exe или 1cv8.exe):

1. Перекачка сырых данных по сети: Когда второй компьютер выполняет запрос с конструкцией ПОДОБНО '%номер%', платформа не может применить стандартные индексы B-Tree. Для выборки клиенту требуется последовательно прочитать всю таблицу целиком. Поскольку файл лежит на удаленной машине, клиент начинает непрерывно выкачивать гигабайты страниц базы данных через протокол SMB в свой локальный кэш.
2. Коллизии блокировок и раздувание файла: При параллельной работе двух пользователей сетевой протокол SMB непрерывно синхронизирует блокировки диапазонов байт внутри одного файла. Возникают коллизии оппортунистических блокировок (Oplocks), сбросы кэша и фрагментация внутренних транзакций. Файловая СУБД 1С при интенсивных блокировках резервирует новые блоки страниц быстрее, чем успевает повторно использовать освобожденные. В результате размер 1Cv8.1CD лавинообразно увеличивается. Физическое освобождение неиспользуемых страниц происходит только после упаковки утилитой chdbfl.exe или процедурой «Тестирование и исправление».
3. Лимит размера внутренней таблицы: В стандартной файловой базе с размером страницы 4 КБ предельный размер одной таблицы не может превышать 4 ГБ. Если справочник физических лиц вместе с контактной информацией приблизится к этой отметке, база аварийно перестанет работать.

Решение 1. Публикация файловой базы на веб-сервере (Apache или IIS)

Это самый надежный, проверенный и рекомендуемый фирмой «1С» способ организации работы 2–3 пользователей с файловой базой. Рассмотрим подробнее, как меняется архитектура при таком подходе:

1. На компьютере первой кассы (где лежит файл 1Cv8.1CD) устанавливается и настраивается бесплатный веб-сервер (Apache 2.4 или встроенный в Windows IIS).
2. База публикуется на веб-сервере с помощью конфигуратора («Администрирование» — «Публикация на веб-сервере»). Модуль веб-сервера работает на том же компьютере и обращается к файлу 1Cv8.1CD напрямую по локальной шине диска.
3. На второй кассе тонкий клиент подключается не по сетевому пути \\Касса1\Base, а по протоколу HTTP к адресу вида http://192.168.1.10/retail_base.

В этой схеме веб-сервер берет на себя роль связующего звена СУБД: все тяжелые выборки данных и сканирование страниц файла происходят локально в оперативной памяти и на быстром SSD первой кассы. На второй компьютер передаются только готовые, сериализованные выборки результатов запроса. Сетевой трафик падает в сотни раз, а проблема блокировок файлов через SMB полностью устраняется.

Решение 2. Оптимизация поисковых запросов и структуры данных

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

1. Отказ от поиска подстроки с начала: Условие вида ПОДОБНО &НомерТелефона со значением параметра "%9167871777%" гарантированно отключает индекс. Если покупатели называют номер телефона, необходимо ввести обязательную нормализацию поля при записи (сохранять только 10 цифр без префиксов «+7», «8» и спецсимволов). Тогда поиск можно выполнять по строгому равенству:
   Скопировать код

   
   ВЫБРАТЬ
       ФизическиеЛицаКонтактнаяИнформация.Ссылка КАК Ссылка,
       ФизическиеЛицаКонтактнаяИнформация.НомерТелефона КАК НомерТелефона
   ИЗ
       Справочник.ФизическиеЛица.КонтактнаяИнформация КАК ФизическиеЛицаКонтактнаяИнформация
   ГДЕ
       ФизическиеЛицаКонтактнаяИнформация.НомерТелефона = &НомерТелефона
   

   По строгому равенству запрос выполнится мгновенно по существующему индексу даже через общую папку.
2. Ограничение объема выборки и валидация длины ввода: Исключим запуск тяжелых запросов при вводе коротких строк (например, если кассир ввел менее 7–8 цифр, поиск не запускается). Дополнительно ограничим максимальное количество возвращаемых записей в самом тексте запроса:
   Скопировать код

   
   ВЫБРАТЬ РАЗЛИЧНЫЕ ПЕРВЫЕ 10
       ФизическиеЛицаКонтактнаяИнформация.Ссылка КАК Ссылка,
       ФизическиеЛицаКонтактнаяИнформация.НомерТелефона КАК НомерТелефона
   ИЗ
       Справочник.ФизическиеЛица.КонтактнаяИнформация КАК ФизическиеЛицаКонтактнаяИнформация
   ГДЕ
       ФизическиеЛицаКонтактнаяИнформация.НомерТелефона ПОДОБНО &НомерТелефона
   

3. Вынос контактных данных из табличной части: Чтение табличной части справочника КонтактнаяИнформация в файловом режиме нередко тянет за собой десериализацию родительского объекта. Хранение нормализованного телефонного номера непосредственно в реквизите справочника или в отдельном независимом непериодическом регистре сведений (где измерение «НомерТелефона» является индексированным) сокращает время выборки в разы.
4. Использование встроенного полнотекстового поиска: Включение полнотекстового поиска для реквизитов контактной информации и регулярное обновление его индекса позволяет выполнять быстрый поиск фрагментов номеров по готовому словарю без полного сканирования физических таблиц.

Решение 3. Тюнинг сетевого стека Windows и протокола SMB

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

1. Отключение кэширования каталогов SMB: На клиенте перейдем в ветку реестра HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters и создадим параметры типа DWORD со значением 0: DirectoryCacheLifetime, FileInfoCacheLifetime и FileNotFoundCacheLifetime. Это предотвратит накопление рассинхронизированного кэша метаданных.
2. Отключение подписи пакетов (SMB Signing): Цифровая подпись SMB-трафика создает избыточную нагрузку на CPU при постоянном чтении страниц файла 1Cv8.1CD. Отключение обязательной подписи пакетов в групповых политиках локальной безопасности существенно снижает сетевые задержки.
3. Отключение аппаратных разгрузок: В свойствах сетевого адаптера отключим опции Large Send Offload (LSO) и TCP Chimney Offload, которые на недорогих сетевых картах часто вызывают скрытые зависания пакетов блокировок.

Альтернативные архитектурные решения без покупки сервера

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

1. Терминальный доступ (RDP / RemoteApp): На компьютере первой кассы настраивается терминальное подключение. Второй кассир запускает 1С внутри сеанса удаленного рабочего стола на первом ПК. В этом случае оба сеанса 1С работают локально в общей оперативной памяти первой машины, не нагружая локальную сеть SMB-пакетами.
2. Разделение данных в РИБ по рабочим местам: Создание узлов РИБ под каждое отдельное кассовое место. Базы на каждой кассе хранятся локально, а обмен чеками и движениями выполняется между кассами в фоновом режиме через общую папку или скрипты выгрузки.