Рассмотрим ситуацию, которая часто встречается в крупных информационных системах на базе 1С:Предприятие. После выполнения тяжелого регламентного задания (например, расчета себестоимости или пересчета партионного учета) пользователи начинают жаловаться, что проведение обычных документов занимает значительное время. При замере производительности выясняется, что «узким местом» является метод Записать() для конкретного регистра накопления, причем время ожидания может достигать десятков секунд на одну операцию.
В этой статье мы подробно разберем, почему возникает такая деградация производительности, как правильно диагностировать проблему и какие шаги предпринять для ее решения. Мы вместе пройдем путь от анализа блокировок до оптимизации настроек SQL-сервера.
Когда документ в 1С проводит записи в регистр накопления, система выполняет несколько операций под капотом. Во-первых, очищаются старые движения документа (если они были). Во-вторых, записываются новые строки в таблицу движений. В-третьих, обновляются итоги в таблице итогов. Если регламентное задание утром массово изменило миллионы строк, структура данных в памяти SQL-сервера и индексы на диске претерпевают серьезные изменения. Проанализируем основные причины, по которым это замедляет последующую работу.
Это самая распространенная причина временного замедления (на 2–3 часа). Оптимизатор запросов SQL-сервера строит планы выполнения на основе статистических данных о распределении значений в таблицах. После того как регламентное задание НаборЗаписей.Записать() массово перезаписало данные, старая статистика перестает соответствовать реальности.
Механизм возникновения проблемы:
Index Scan вместо быстрого Index Seek.Для решения этой проблемы мы рекомендуем добавить в конец вашего регламентного задания принудительное обновление статистики. Рассмотрим пример кода на языке T-SQL, который можно вызвать через COMОбъект или выполнить в консоли SQL:
-- Обновление статистики для конкретной таблицы регистра
UPDATE STATISTICS _AccumReg123 WITH FULLSCAN;
В рамках самой платформы 1С мы можем использовать средства управления итогами, что также косвенно инициирует обновление данных на уровне СУБД.
Массовое удаление и вставка записей в регистр накопления (особенно если записи вставляются «в середину» временной шкалы) приводит к сильной фрагментации индексов. Когда обычный документ пытается записать свои движения, SQL-сервер вынужден выполнять операцию Page Split (расщепление страниц), чтобы найти место для новых данных. Это требует значительных ресурсов дисковой подсистемы.
Выясним, является ли это причиной в вашем случае. Попробуем запустить процесс в монопольном режиме. Если в монопольном режиме документ проводится быстро, значит, проблема в параллельных блокировках. Если так же медленно — дело в физической структуре таблиц (индексы, статистика, фрагментация).
Регистры накопления крайне чувствительны к актуальности итогов. Проанализируем ситуацию, когда расчет себестоимости создает множество записей, которые в сумме дают ноль по измерениям. В таблице итогов 1С могут оставаться «пустые» записи с нулевыми значениями.
Что нужно проверить:
Записать() будет пересчитывать их «на лету» от ближайшей рассчитанной точки, что крайне медленно.Попробуем временно отключить итоги у регистра для теста производительности (в копии базы!). Рассмотрим, как это сделать программно:
РегистрыНакопления.ИмяВашегоРегистра.УстановитьИспользованиеИтогов(Ложь);
// Попробуем провести документ. Если стало быстро — проблема в расчете итогов.
РегистрыНакопления.ИмяВашегоРегистра.УстановитьИспользованиеИтогов(Истина);
Несмотря на то, что регламентное задание формально завершено, в системе могут остаться зависшие транзакции или фоновые процессы, которые 1С запускает автоматически (например, обновление агрегатов или слияние полнотекстового поиска). Метод Записать() блокирует таблицу итогов по набору измерений. Если в этот момент другой процесс держит блокировку, мы получим задержку.
Разобрать эту ситуацию поможет «Центр управления производительностью» (ЦУП) или обычный консольный мониторинг SQL-сервера. Обратим внимание на тип ожидания LCK_M_X (Exclusive Lock).
Для устранения проблемы «зависания» на 28 секунд при записи, пройдем по следующему алгоритму:
UPDATE STATISTICS.Конфигуратор -> Администрирование -> Тестирование и исправление или через управление итогами в пользовательском режиме.VACUUM ANALYZE. В этой СУБД после массового обновления данных таблицы заполняются «мертвыми» кортежами, которые замедляют чтение и запись до тех пор, пока очистка не будет произведена физически.Важный совет: Если регламентное задание выполняется в 7 утра, а работа начинается в 8, попробуйте перенести запуск задания на более раннее время (например, на 3 часа ночи), чтобы у SQL-сервера было время на автоматическое выполнение фоновых задач обслуживания до прихода пользователей.
Проанализировав все факторы — от логики работы НаборЗаписей до планов запросов СУБД — вы сможете добиться стабильной и быстрой работы системы даже при очень больших объемах данных в регистрах накопления.