Многие технические специалисты, занимающиеся сопровождением нескольких баз 1С:Предприятие 8.3 в файловом режиме, сталкиваются с парадоксальной ситуацией: абсолютно одинаковые, типовые конфигурации (например, 1С:Бухгалтерия 3.0), находящиеся на одном и том же сервере или диске, обновляются с разной скоростью. При этом часто наблюдается аномалия, когда база меньшего объема обновляется в два-три раза медленнее, чем более крупная база. В этой статье мы подробно разберем, почему так происходит, и какие шаги нужно предпринять, чтобы нормализовать скорость обновления.
Для начала проанализируем ситуацию: базы находятся «на замке» (полностью типовые), работают на одной платформе и обновляются одним и тем же инструментом (например, «Обновлятором» или вручную через Конфигуратор). На первый взгляд, условия идентичны, но на производительность файловой системы 1С влияют скрытые факторы. Разберем их по порядку.
1. Состояние Журнала регистрации (Event Log)
Одной из самых частых причин замедления является разрастание журнала регистрации. В файловых базах журнал может храниться в старом формате .lgp (набор файлов в папке 1Cv8Log) или в новом формате SQLite (файл 1Cv8.lgd). При обновлении конфигурации система фиксирует каждое изменение метаданных в журнале. Если лог-файл весит несколько гигабайт или содержит миллионы записей, время отклика файловой системы на запись каждого нового события существенно возрастает. В разных базах интенсивность ведения учета разная, следовательно, и объем логов различается, что напрямую влияет на этап принятия изменений.
2. Внутренняя фрагментация файла базы данных .1CD
Рассмотрим устройство файловой базы. Файл .1CD — это по сути контейнер для СУБД. В процессе работы, удаления и добавления данных внутри этого контейнера возникает фрагментация. Даже если физический диск (HDD или SSD) дефрагментирован средствами Windows, внутри файла базы данных таблицы могут быть расположены неоптимально. Это приводит к тому, что при обновлении (особенно на этапе реструктуризации) головки жесткого диска или контроллер SSD совершают избыточные операции чтения-записи.
Выясним, как устранить эти задержки. Рассмотрим метод, который помог автору темы, и дополним его профессиональными рекомендациями по обслуживанию файловых баз.
Проанализируем самый эффективный способ быстро «сбросить» накопленные замедления. Часто проблема кроется не в самих данных, а в сопутствующем «мусоре» в папке базы данных. Выполним следующие действия:
1Cv8.1CD из проблемной базы. Не копируем папки кэша, логи и временные файлы.Как показывает практика, этот метод позволяет выровнять скорость обновления нескольких баз, так как при этом отсекаются старые логи и битые индексы кэша.
Разберем ситуацию с кэшем. 1С сохраняет временные данные в профиле пользователя (директории %AppData%\Local\1C и %AppData%\Roaming\1C). Для каждой базы создается уникальный идентификатор (GUID). Если кэш конкретной базы поврежден или перегружен старыми метаданными, процесс сравнения и объединения конфигураций будет тормозить. Рекомендуется перед обновлением очистить кэш. В «Обновляторе» это можно настроить автоматически, а вручную это делается удалением базы из списка и добавлением её заново (при этом создается новая папка кэша с новым GUID).
Для устранения внутренней фрагментации и ошибок структуры базы выполним стандартные процедуры обслуживания:
bin установленной платформы. Она проверяет физическую целостность файла .1CD.Посмотрим на ситуацию шире. Если программные методы не помогают, стоит проверить аппаратную часть и настройки операционной системы.
1. Работа антивируса
Проанализируем поведение антивирусного ПО. При обновлении 1С активно создает и удаляет временные файлы. Если папка с одной базой по какой-то причине не попала в исключения антивируса, каждый записываемый блок данных будет проверяться «на лету», что замедлит процесс в несколько раз. Убедимся, что расширения .1CD, .1CL, .lgp, .lgd добавлены в доверенную зону.
2. Особенности SSD (SLC-кэш)
Если базы лежат на бюджетном SSD, важно учитывать наличие SLC-кэша. Рассмотрим сценарий: вы запускаете обновление пяти баз подряд. Первая база обновляется на высокой скорости, заполняя быстрый буфер диска. К моменту обновления третьей или четвертой базы буфер переполняется, и контроллер диска начинает писать данные напрямую в медленные ячейки памяти. Это объясняет, почему базы, обновляемые последними, могут работать медленнее.
3. Фоновые задания
В типовых конфигурациях БП 3.0 настроено множество регламентных заданий (загрузка курсов, классификаторов, расчеты). В файловом режиме они могут запускаться сразу после того, как обновление конфигурации завершено и база открывается для выполнения обработчиков обновления. Если в одной базе накопилось больше невыполненных заданий, она будет дольше «висеть» на этапе завершения обновления.
Подведем итоги. Если ваши типовые базы обновляются с разной скоростью, выполните следующие действия: проведите сжатие таблиц через ТиИ, очистите кэш пользователя и попробуйте переместить файл 1Cv8.1CD в новую директорию без переноса старого журнала регистрации. В большинстве случаев это сокращает время обновления в 2-2.5 раза и приводит все базы к единому знаменателю производительности.