При переходе с редакции 1С:ERP 2.4 на версию 2.5 многие специалисты сталкиваются с серьезной проблемой производительности. Выполняя тестовое обновление базы, мы можем заметить, что процесс реструктуризации проходит нормально, однако при первой попытке выполнить процедуру Закрытие месяца система надолго "задумывается". Особенно остро это проявляется на этапах распределения затрат и расчета себестоимости. Одновременно с этим системная база данных tempdb в MS SQL Server начинает стремительно разрастаться, заполняя выделенные 10, 30 и более гигабайт, что в итоге может привести к аварийному прерыванию процесса.
Давайте подробно разберем, проанализируем эту ситуацию и выясним причину такого поведения системы, а также рассмотрим технические шаги, которые помогут успешно завершить переход и оптимизировать работу конфигурации.
В первую очередь посмотрим на то, как изменилась логика работы программы. В редакции 2.5 разработчики 1С существенно переработали механизмы предварительного и окончательного расчета себестоимости.
Если в версии 2.4 предварительный расчет считал себестоимость упрощенно, "по средней", и записывал результаты только в один специализированный регистр, то в версии 2.5 архитектура стала намного сложнее. Теперь предварительное закрытие месяца умеет полноценно распределять партии, формировать детальные движения по финансовым регистрам и учитывать глубокие настройки учетной политики организации. Из-за этого количество формируемых движений и промежуточных временных таблиц при закрытии месяца возрастает многократно.
Разберем по шагам, что происходит под капотом СУБД во время этапов "Настройка распределения расходов", "Заполнение партий" и при построении сложных графов (цепочек) затрат:
MS SQL Server перестает держать эти таблицы в RAM.tempdb.Кроме того, первое закрытие месяца после обновления на 2.5 всегда самое тяжелое. Программа вынуждена обрабатывать и конвертировать огромные массивы исторических данных, перестраивать старые остатки из-за перехода на онлайн-взаиморасчеты и новую архитектуру партионного учета. Поэтому рост tempdb свыше 30–50 ГБ, а в крупных системах и до нескольких сотен гигабайт, является штатным и ожидаемым поведением.
Ограничивать размер tempdb "смехотворными" 10 ГБ при переходе на ERP 2.5 категорически нельзя. Чтобы процесс не зависал и проходил максимально быстро, администраторам баз данных необходимо выполнить тонкую настройку сервера. Выполним следующие рекомендации:
tempdb на несколько физических файлов данных. Рекомендуется создавать от 4 до 8 равных по размеру файлов в зависимости от количества логических ядер вашего процессора. Это снимет внутренние блокировки сервера (PAGELATCH-ожидания) при параллельном обращении множества потоков 1С к системным страницам памяти.tempdb. Во время приращения файла транзакция 1С ставится сервером "на паузу", что критически замедляет закрытие месяца. Сразу выделите под tempdb достаточный объем (например, 100-200 ГБ). Автоприрост оставьте только как страховку, задав ему большой шаг (от 1 до 5 ГБ), а не стандартные мегабайты.tempdb на самые быстрые из доступных накопителей. Идеальным вариантом будут SSD стандарта NVMe или даже RAM-диск (созданный в оперативной памяти). Файлы tempdb должны располагаться на отдельных физических дисках от основных файлов базы данных 1С и логов транзакций.Как справедливо отмечают эксперты, переход на 2.5 — это повод пересмотреть аппаратные мощности. Вам потребуется больше оперативной памяти и более быстрые диски.
Посмотрим на настройки самой конфигурации, которые могут влиять на скорость работы. В ERP 2.5 появилась новая опция в учетной политике — Выделение отклонений себестоимости окончательного расчета от результата предварительного расчета. Если эта настройка включена, система при окончательном закрытии месяца порождает колоссальное количество дополнительных корректирующих записей в регистрах. Это может экспоненциально увеличить время на этапе записи сформированных движений. Если выделение отклонений не является строгим требованием ваших финансистов, эту опцию лучше отключить.
Также проанализируем версию вашей платформы и конфигурации. Обязательно обращайте внимание на список исправленных ошибок в релизах. Например, в версии 2.5.7.366 присутствовала признанная разработчиками проблема с неоптимальными запросами, из-за которой скорость закрытия месяца падала в десятки раз. В последующих сборках (например, в 2.5.7.383 и старше) эти запросы были оптимизированы. Всегда старайтесь обновляться на самые актуальные патчи и релизы внутри целевой ветки перед тем, как запускать ресурсоемкое закрытие месяца.
Подводя итог, помните: самое долгое и тяжелое закрытие — первое. Как только программа реструктуризирует исторические остатки и сформирует структуру партий по новым правилам, последующие рутинные закрытия месяцев будут проходить значительно быстрее и требовать меньше ресурсов системы.