Разработчики и администраторы крупных прикладных решений на платформе 1С (таких как «Бухгалтерия предприятия 3.0», «ERP Управление предприятием» или «Комплексная автоматизация») часто сталкиваются с крайне неприятной проблемой. При обновлении измененной конфигурации, которая частично или полностью снята с поддержки (на замке отсутствуют некоторые объекты), процесс намертво зависает на этапе «Сохранение конфигурации...». Это ожидание может растягиваться на 30–40 минут, а иногда и на несколько часов.
В то же время с абсолютно типовыми конфигурациями, находящимися на полной поддержке поставщика, подобные операции выполняются за считанные минуты. В этой статье мы подробно проанализируем технические причины такого поведения платформы, разберем влияние дисковой подсистемы СУБД и предложим эффективные практические сценарии, позволяющие сократить время сохранения базы данных в несколько раз.
Для того чтобы понять природу возникновения задержек, заглянем под капот платформы 1С и СУБД. В СУБД (будь то Microsoft SQL Server или PostgreSQL) данные самой конфигурации хранятся в специальных системных таблицах. Ключевыми здесь являются таблицы Config (в ней хранится основная конфигурация базы данных) и ConfigSave (сюда записываются промежуточные изменения при нажатии клавиш Ctrl+S в Конфигураторе).
Данные конфигурации хранятся внутри этих таблиц в виде тяжелых бинарных полей (так называемые BLOB-объекты). Когда конфигурация находится на полной поддержке («на замке»), платформа 1С четко знает структуру метаданных поставщика и при обновлении производит минимум изменений в структуре хранения. Однако, как только мы снимаем конфигурацию с поддержки (разрешаем редактирование) и добавляем собственные реквизиты, справочники или документы, процесс обновления кардинально меняется:
ConfigSave..ldf в MS SQL или сегменты WAL в PostgreSQL) и только после этого зафиксировать изменения в основном файле данных (.mdf).Бутылочное горлышко дисковой подсистемы. Запись в журнал транзакций всегда происходит строго последовательно (однопоточно). Если файл лога СУБД расположен на медленном шпиндельном жестком диске (HDD), головка диска физически не успевает позиционироваться для совершения тысяч мелких операций записи в секунду. В результате возникает огромная дисковая очередь.
Выяснить эту причину можно с помощью системного монитора производительности операционной системы. Проанализируем ключевой показатель — «Средняя длина очереди к диску» (Avg. Disk Queue Length) для того тома, где лежат файлы баз данных. Если этот показатель превышает значение 2 (для одиночного накопителя), диск перегружен. Перенос самого SQL-сервера и системного диска на твердотельный накопитель (SSD) не решит проблему, если файлы логов транзакций (.ldf) по старой привычке администраторов остались лежать на медленном HDD. Для решения проблемы необходимо перенести файлы журналов транзакций на быстрый SSD или NVMe-накопитель.
Если серверная база данных находится в промышленной эксплуатации, проводить тяжелые сравнения и объединения непосредственно на рабочем сервере «в лоб» — крайне неэффективное решение. Процесс сравнения метаданных нагружает процессор и оперативную память сервера приложений, создавая неудобства для пользователей.
Разберем по шагам профессиональный и быстрый алгоритм обновления измененной конфигурации:
.cf через меню «Конфигурация» -> «Сохранить конфигурацию в файл...»..cf.При использовании операции «Загрузить конфигурацию из файла» платформа 1С не производит пообъектное сравнение и частичную перезапись метаданных. Она полностью замещает структуру таблиц конфигурации готовым слепком. Это исключает генерацию миллионов мелких транзакций, и сохранение изменений на сервере происходит в разы (а иногда и в десятки раз) быстрее.
Наиболее надежный архитектурный способ решения проблемы медленного сохранения измененной конфигурации — это возвращение основной конфигурации на полную поддержку («на замок»). Достигается это за счет переноса всех доработок в механизм Расширений конфигурации.
Если добавленные справочники, документы или реквизиты будут созданы в рамках отдельного расширения, основная конфигурация останется абсолютно типовой. Это дает колоссальные преимущества:
Рассмотрим пример того, как программно в коде расширения можно безопасно перехватывать и дорабатывать поведение типовых механизмов, не снимая основную конфигурацию с поддержки. Например, нам нужно добавить логику при записи документа:
&Вместо("ПередЗаписью")
Процедура Расш_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Выполняем типовой код системы
ПродолжитьВызов(Отказ, РежимЗаписи, РежимПроведения);
// Добавляем нашу кастомную бизнес-логику
Если Не Отказ Тогда
// Вызов нашей процедуры обработки
Расш_ВыполнитьДополнительныеПроверки();
КонецЕсли;
КонецПроцедуры
Использование аннотации &Вместо позволяет полностью сохранить логику работы типового решения, аккуратно внедрив туда собственные алгоритмы, при этом конфигурация останется полностью на замке.
Еще одной неочевидной причиной зависания на этапе сохранения изменений является запуск Конфигуратора на локальном компьютере разработчика, когда сам сервер 1С и СУБД находятся в удаленном контуре (например, в облаке или в офисе, к которому разработчик подключен по VPN).
Во время сохранения конфигурации между клиентом (Конфигуратором) и сервером приложений 1С происходит непрерывный обмен огромным количеством пакетов данных (Round-Trip). Даже если скорость интернет-соединения составляет 100 Мбит/с, физическая задержка пакета (ping) в 15–20 мс приведет к тому, что операция, занимающая на сервере 1 минуту, через VPN будет выполняться целый час.
Правило разработки: Любые тяжелые административные действия с конфигурацией (сравнение, объединение, сохранение, обновление базы данных) должны выполняться исключительно на терминальном сервере (через RDP), расположенном в той же локальной сети, что и сервер приложений 1С и сервер СУБД. Запуск Конфигуратора через медленные каналы связи для сохранения тяжелых метаданных категорически не рекомендуется.
Современная «Бухгалтерия предприятия 3.0» в распакованном виде в памяти занимает огромный объем. Если для работы используется 32-разрядный клиент 1С (файл 1cv8.exe), процесс Конфигуратора ограничен лимитом адресного пространства в 2 ГБ (или до 4 ГБ при наличии флага LAA).
При объединении измененной базы с конфигурацией поставщика объем потребляемой памяти легко упирается в этот лимит. Конфигуратор не выдает ошибку нехватки памяти сразу, а переходит в режим непрерывного свопинга (сброса данных на диск в файл подкачки) и постоянной работы сборщика мусора (Garbage Collector). Процессор загружен на 100%, но полезная работа практически не совершается. Чтобы этого избежать, всегда используйте для разработки 64-разрядную версию платформы 1С клиента.
Длительное сохранение конфигурации может быть следствием сильного раздувания таблиц метаданных из-за частого использования механизма динамического обновления («демонских» обновлений). При динамическом обновлении старые версии конфигураций не удаляются сразу, а помечаются как неактивные и продолжают храниться в таблице Config, увеличивая ее размер до гигантских масштабов.
Для исправления ситуации выполните следующие действия:
%localappdata%\1C\1Cv8.Систематический контроль за состоянием дисковой системы, отказ от внесения правок непосредственно в основную конфигурацию в пользу расширений, а также правильная организация процесса обновления через локальные файловые копии позволят вам навсегда забыть о томительном ожидании при сохранении конфигурации 1С.