История расследования (с бонусами) взаимоблокировок на таблице итогов регистра бухгалтерии

22.05.23

База данных - HighLoad оптимизация

Мой первый опыт расследования взаимоблокировок на таблице итогов регистра бухгалтерии на новом месте работы.

Отраслевая конфигурация, доработанная, на регистрах бухгалтерии и управляемых блокировках.

В журнал регистрации пишется достаточно большое количество событий о взаимоблокировках на СУБД при одновременном выполнении загрузки регламентными заданиями разных объектов конфигурации.

Доступы мне только начали выдавать и я запустил профайлер MS SQL с одним лишь событием "Deadlock graph". Быстро "поймалось" нужное событие:

 

 

По метаданным это таблица "ИтогиМеждуСчетами" регистра бухгалтерии, кластерный не уникальный индекс. По характеру взаимоблокировки - скан таблицы при неоптимальном запросе. Но это системная таблица итогов механизмов 1С, там нет самописных пользовательских запросов.

К этому времени мне уже дали доступ к серверам 1С и я настроил технологический журнал на сбор события DBMSSQL только для таблицы "%_AccRgCT76484%", планов запросов и информации о взаимоблокировках, а в профайлере MS SQL дополнительно запустил сбор событий "Lock:Acquired" с фильтром по проблемной таблице и только для U (4) и X (5) блокировок.

Взаимоблокировка поймалась за 2 часа, по логу профайлера было видно, что это настоящий скан таблицы итогов. Из собранного ТЖ я получил план запроса:

 

 

Видно, что тут использовался индекс, поскольку оператор Clustered Index Seek, но посмотрев повнимательнее, видим, что Seek идет только по разделителю данных и периоду (а других столбцов у данного индекса и вообще нет), а после Seek идет Where, что означает, что происходит сканирование данных. На всякий случай (у таблицы существует ещё 2 индекса) обновил статистику, реиндексацию индексов, очистил процедурный кэш - ничего не помогло.

Собрал и посмотрел план запроса для типового регистра Хозрасчётный:

 

 

Совершенно другая ситуация! Полноценное использование двух индексов, без каких-либо условий.

Открыл структуру таблиц в SSMS, сравнил визуально, проблемная таблица итогов:

 

 

Индекс не уникальный, "потерян" реквизит механизма разделения итогов. Для верификации создал чистую ИБ на платформе 8.3.23.1688 и MS SQL 2019, там ситуация практически такая же:

 

 

Только в столбцы таблицы добавился "_DimHash" (в индексе его нет так же ка и "_Splitter"). При этом в свежей версии официальной документации "структура данных" он вообще не упоминается:

 

 

но зато при этом упоминается в разделе "индексы таблиц":

 

 

"ХэшИзмерений" - это вероятно не работающий аналог "DimHash" регистра накопления:

 

 

который в свою очередь так же, вероятно, не полностью рабочий:

 

 

Т.е. искусственный реквизит специально разработан для организации уникального индекса, присутствует и в столбце и в ключе индекса, но у индекса не установлен признак "Уникальный".

После этого я сел и сверил официальную документацию и реальную структуру БД для регистров (сведений, накопления, бухгалтерии), выявил 16 "инцидентов" (ошибок, замечаний и т.п.). К примеру, для регистра сведений, если его измерения имеют составной тип данных создаются вот такие индексы, не бьющиеся ни с официальной документацией, ни со здравым смыслом:

 

 

Делаю вывод - существует масса проблем и ошибок, связанных с ограничением на 16 ключей индекса БД (а почему 16, а не 32? MS SQL начиная с версии 2016 имеет ограничение 32, а postgresql вообще ещё раньше мне кажется это поддерживал) при большом реквизитном составе метаданных, некорректно работающих механизмов искусственного нивелирования ситуации ("DimHash") и применению реквизитов с составным типом данных в индексах.

Письмо в 1С написал, поправьте меня в комментариях, если не прав, это мой первый опыт такого разбора.

См. также

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    5700    ivanov660    4    

61

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    3631    a.doroshkevich    20    

64

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    13583    skovpin_sa    14    

82

«Монитор» – простой анализ производительности

Администрирование СУБД Технологический журнал Бесплатно (free)

Для расследования проблем производительности недостаточно просто проанализировать технологический журнал. Нужен парсинг контекста событий, его сопоставление с информацией из Extended Events и логов, агрегация огромного количества информации.

21.09.2023    4595    Andreynikus    14    

77

Как эффективно настроить autovacuum в Postgres для 1С

HighLoad оптимизация Администрирование СУБД Платформа 1С v8.3 Бесплатно (free)

Кто не любит убирать мусор? Думаю, практически все, а вот в Postgres это обязательный ритуал для эффективной работы. Как эффективно настроить уборку за 1С в Postgres, можно прочитать в этой статье и еще раз задуматься о бесплатности Postgres.

05.08.2023    4210    1CUnlimited    5    

48

MS SQL Server: изучаем планы запросов

Запросы HighLoad оптимизация Запросы Бесплатно (free)

Многие знают, что для ускорения работы запроса нужно «изучить план». При этом сам план обычно обескураживает: куча разноцветных иконок и стрелочек; ничего не понятно, но очень интересно! Аналитик производительности Александр Денисов на конференции Infostart Event 2021 Moscow Premiere рассказал, как выполняется план запроса и что нужно сделать, чтобы с его помощью находить проблемы производительности.

20.06.2023    10865    Филин    37    

101
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. TMV 14 27.05.23 15:30 Сейчас в теме
В чем вас поправить? В том, что из-за составных типов измерений вы столкнулись с ограничением в 16 полей индекса?
triviumfan; +1 Ответить
2. i_lo 214 30.05.23 09:50 Сейчас в теме
Операция короткая. Помогает ли исключительная блокировка всей таблицы? Хотя бы временно. Ожидание лучше взаимоблокировки.
Оставьте свое сообщение