← На главную
Перевод рабочей базы «1С:Бухгалтерия предприятия» с редакции 2.0 на 3.0 при сохранении файлового режима работы часто вызывает множество вопросов у системных администраторов и специалистов по внедрению. Если в старой редакции на обычных формах полтора-два десятка пользователей могли работать в терминальном сервере без критических задержек, то в редакции 3.0 на управляемых формах архитектура взаимодействия с базой существенно меняется. Разберем технические особенности, с которыми предстоит столкнуться при такой конфигурации, выясним причины потенциальных зависаний и рассмотрим способы адаптации системы.
В чем разница между БП 2.0 и БП 3.0 в файловом режиме
Проанализируем ключевое отличие между редакциями. Конфигурация «Бухгалтерия предприятия 2.0» использовала обычные формы и толстый клиент. В управляемом интерфейсе редакции 3.0 при файловом размещении базы каждый процесс тонкого клиента вынужден совмещать функции клиента и сервера приложений на одной рабочей станции или внутри одной терминальной сессии. Это приводит к следующим особенностям:
- Повышенное потребление оперативной памяти: сеанс БП 2.0 требовал сравнительно небольшого объема RAM, тогда как один сеанс БП 3.0 занимает от 800 МБ до 1,5–2 ГБ оперативной памяти. На 20 активных подключений в терминале потребуется выделить не менее 32–48 ГБ оперативной памяти исключительно под работу процессов программы.
- Нагрузка на дисковую подсистему: логика работы управляемого приложения генерирует большой поток временных файлов, кэша и обращений к базе данных, поэтому работа на традиционных жестких дисках (HDD) становится невозможной.
- Служебные фоновые процессы: в конфигурации 3.0 по умолчанию активирован большой пул регламентных операций (проверка контрагентов, загрузка курсов валют, обновление классификаторов, расчет остатков), которые выполняются параллельно с действиями пользователей.
Механизм блокировок данных в файловой базе
Главным узким местом при конкурентной работе большого количества пользователей выступает не вычислительная мощность процессора, а архитектура транзакционных блокировок файлового формата 1Cv8.1CD. Выясним причину, почему проведение документов вызывает наибольшие задержки:
В клиент-серверном режиме (SQL) СУБД способна накладывать блокировки на уровне отдельных строк таблиц. Если один бухгалтер проводит реализацию по одной организации или номенклатуре, а второй вносит документ по другой, они не мешают друг другу. В файловом режиме при проведении документа блокируется вся таблица регистра или объекта целиком. Поскольку большинство документов бухгалтерского учета формируют записи в едином регистре бухгалтерии, параллельное проведение документов становится физически невозможным: транзакции выстраиваются в очередь.
Если интенсивность ввода небольшая (например, оформляется 1–2 документа в минуту), пользователи практически не заметят ожидания. Однако в периоды пиковой нагрузки, закрытия месяца или одновременного перепроведения документов система начнет выдавать ошибки ожидания блокировки данных.
Архитектурные риски файлового формата при 20 пользователях
Рассмотрим скрытые риски, которые необходимо учитывать перед принятием решения о сохранении файловой базы:
- Ограничение на размер внутренних таблиц: стандартный размер страницы базы данных накладывает лимит в 4 ГБ на любую отдельную таблицу внутри файла
1Cv8.1CD. В активной базе «Бухгалтерии предприятия» таблицы итогов регистров бухгалтерии и версионирования быстро приближаются к этому порогу. - Уязвимость к сбоям и целостность базы: при работе 20 человек в терминале аварийное завершение сеанса одного из пользователей или перезагрузка сервера во время открытой транзакции легко приводит к повреждению внутренней структуры базы данных. В файловом формате отсутствует развитый механизм журнала транзакций, что вынуждает системного администратора регулярно восстанавливать базу утилитой
chdbfl.exe. - Ограничения публикации через веб-сервер: использование веб-серверов (Apache или IIS) позволяет снизить накладные расходы терминала, однако встроенный коннектор файловой базы нестабильно распределяет параллельные обращения. При одновременной нагрузке более 8–10 активных пользователей пул веб-сервера может сталкиваться с таймаутами.
Оптимизация файловой базы: пошаговый план
Если перевод на клиент-серверный вариант временно невозможен, настроим конфигурацию и окружение для максимальной производительности. Разберем необходимые действия по шагам:
- Обеспечение аппаратной базы: обязательно разместим файл информационной базы и терминальные профили пользователей на быстрых накопителях NVMe SSD с высоким показателем IOPS.
- Отключение некритичных регламентных заданий: перейдем в меню администрирования регламентных и фоновых заданий и перенесем на ночные часы все второстепенные задачи (загрузка курсов валют, проверка контрагентов, новости, расчет показателей).
- Отключение полнотекстового поиска: снимем активность полнотекстового поиска данных и выполним очистку индекса. Это заметно сократит количество дисковых операций записи и уменьшит объем служебных таблиц.
- Хранение файлов вне базы данных: настроим хранение присоединенных файлов (сканов счетов, договоров) в томах на диске, чтобы исключить разрастание файла базы данных.
- Отключение или ограничение версионирования: деактивируем версионирование объектов для документов массового ввода (платежные поручения, реализации, поступления), оставив его только для ключевых справочников.
- Регулярная очистка кэша: настроим периодическое удаление временных файлов сеансов пользователей в каталогах
AppData на терминальном сервере, предотвращая сбои интерфейса.
Альтернативные варианты организации работы
Если в процессе эксплуатации пользователи регулярно сталкиваются с зависаниями и блокировками, рассмотрим альтернативные сценарии модернизации инфраструктуры:
- Переход на связку «Сервер 1С:Предприятия» + СУБД PostgreSQL: использование бесплатной СУБД с открытым исходным кодом позволяет исключить затраты на коммерческие лицензии баз данных. Расходы в этом случае ограничатся только покупкой серверной лицензии «1С:Предприятие 8». Это решит проблему табличных блокировок и снимет риск разрушения файлов базы.
- Использование распределенной информационной базы (РИБ): если учет ведется по нескольким независимым организациям или удаленным подразделениям, разделим систему на узлы РИБ с периодической ночной синхронизацией.
- Переход в облачные сервисы: при нежелании сопровождать собственную серверную инфраструктуру эффективным выходом становится аренда базы в готовом облаке, где работа уже организована на отказоустойчивых кластерах серверов.