Рано или поздно любая развивающаяся компания сталкивается с проблемой, когда привычная и простая в обслуживании файловая база «1С:Предприятие» начинает безжалостно зависать. Типичный сценарий: в базе работают 15–20 человек, конфигурация типовая (например, «1С:Управление нашей фирмой» или «1С:Управление торговлей»), но в пиковые моменты пользователи начинают жаловаться, что простые операции — открытие формы, проведение документа или формирование небольшого отчета — занимают минуты. При этом замеры производительности показывают, что простейший запрос на чтение данных может выполняться десятки секунд.
В этой статье мы подробно разберем, почему файловая СУБД 1С ведет себя подобным образом, выясним причины блокировок, проанализируем влияние сетевой инфраструктуры и предложим пошаговые сценарии оптимизации — от бесплатных «лайфхаков» до полноценного перехода на клиент-серверную архитектуру.
Для начала разберем природу файловой СУБД «1С:Предприятие 8». Вся база данных физически представляет собой один файл с расширением 1Cv8.1CD. В отличие от полноценных систем управления базами данных (таких как MS SQL Server или PostgreSQL), файловая СУБД 1С имеет крайне упрощенный механизм управления транзакциями и блокировками.
Рассмотрим детально, как происходят процессы чтения и записи в файловом режиме:
Поэтому медленная работа запросов на чтение в многопользовательской файловой базе — это почти всегда следствие жестких транзакционных блокировок при записи со стороны других сеансов.
Если ваши 16 пользователей работают с файловой базой, которая просто лежит в общей сетевой папке (по протоколу SMB/Samba), это самый неэффективный сценарий из всех возможных. При такой схеме каждый клиентский компьютер берет на себя роль «движка» СУБД, прокачивая через локальную сеть огромные объемы сырых данных из файла базы.
Переход на публикацию базы через веб-сервер (Apache или IIS) позволяет кардинально изменить архитектуру взаимодействия:
1Cv8.1CD.Важное предостережение: Переход на веб-сервер существенно разгрузит сеть и процессоры клиентских ПК, но он не решает проблему табличных блокировок в самом файле базы данных. Если зависания были вызваны именно транзакционными коллизиями, веб-сервер лишь немного сгладит углы, но не устранит проблему полностью.
Мало кто знает, что производительность файловой базы можно существенно поднять «малой кровью», изменив внутренний формат хранения данных. По умолчанию новые файловые базы 1С создаются с размером страницы данных, равным 4 Кб. При активной работе большого количества пользователей это приводит к фрагментации файла и снижению скорости дисковых операций ввода-вывода (IOPS).
Мы можем принудительно увеличить размер страницы до 64 Кб с помощью штатной утилиты конвертации:
1Cv8.1CD. Это критически важно!C:\Program Files\1cv8\8.3.XX.XXXX\bin\) утилиту CNVDBFL.EXE.После увеличения размера страницы до 64 Кб база данных начинает работать ощутимо быстрее на современных твердотельных накопителях (SSD/NVMe), так как размер блока данных 1С синхронизируется с физической архитектурой работы ячеек памяти современных дисков. Кроме того, это увеличивает максимально допустимый размер одной таблицы базы данных с 4 Гб до нескольких десятков гигабайт.
Ограничение прав на уровне записей (RLS — Record Level Security) — это мощный инструмент безопасности, но для файловой базы это «приговор» производительности при 16 пользователях.
Когда включен RLS, платформа неявно модифицирует каждый запрос пользователя. Например, вместо простого запроса:
ВЫБРАТЬ
Ссылка,
Номер,
Дата
ИЗ
Документ.ЗаказПокупателя
Платформа выполняет сложнейшую конструкцию с проверкой прав:
ВЫБРАТЬ
Ссылка,
Номер,
Дата
ИЗ
Документ.ЗаказПокупателя
ГДЕ
Ответственный В (ВЫБРАТЬ Пользователь ИЗ РегистрСведений.ГруппыДоступаПользователей ГДЕ ...)
Для файловой базы такие вложенные запросы оборачиваются полным сканированием таблиц (Full Table Scan) вместо поиска по индексам. Если отказаться от RLS невозможно, обязательно проверьте следующие настройки в вашей «1С:УНФ»:
КлючиДоступаКОбъектам, что избавляет систему от необходимости динамических вычислений на лету.Иногда причиной зависания конкретного отчета или формы является отсутствие индекса по полю, которое участвует в частых отборах. Проанализируем простейший пример. Если у вас в запросах или динамических списках часто используется отбор по реквизиту «Контакт» (или любому другому кастомному реквизиту), этот реквизит обязательно должен быть проиндексирован.
Разберем, как проверить индексацию в конфигураторе:
Индексирование создает специальную упорядоченную структуру, которая позволяет файловой СУБД мгновенно находить нужные строки без последовательного перебора миллионов записей на диске.
Давайте смотреть правде в глаза. Работа 16 активных пользователей в современной конфигурации УНФ на файловой базе — это постоянная жизнь «на пороге катастрофы». Платформа «1С:Предприятие 8» изначально проектировалась с расчетом на то, что для работы более 5–8 пользователей требуется клиент-серверный вариант (SQL).
Рассмотрим, какие преимущества дает переход на клиент-серверную архитектуру:
1Cv8.1CD при аварийном завершении работы компьютера (например, при отключении электричества) легко может повредиться. В клиент-серверном варианте база защищена механизмами транзакционных логов СУБД, а резервное копирование можно настроить в горячем режиме без выгона пользователей.Для небольших компаний отличным решением по соотношению цена/качество будет связка бесплатной СУБД PostgreSQL (рекомендуется использовать специализированную сборку Postgres Pro для 1С) и серверной лицензии 1С. Для небольших офисов также существует бюджетная «Лицензия на сервер МИНИ» (ограничение до 5 подключений), но в рассматриваемом случае (16 пользователей) потребуется полноценная 64-разрядная лицензия на сервер «1С:Предприятия».
Если ваша файловая база 1С начала критически тормозить при работе группы пользователей, рекомендуем действовать по следующему плану:
CNVDBFL.EXE переведите размер страницы данных на 64 Кб.