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

1. Kernelbug 54 11.06.24 18:44 Сейчас в теме
Доброго вечера, коллеги.

Возможно, кто-то расскажет, что находится "под капотом" у следующей проблемы и как её можно победить непрямыми методами.

Суть: на разных платформах, как минимум начиная с 8.3.20 (пусть для определённости будет 8.3.22.1750), на разных ОС (и Виндовс, и Линукс) на СУБД Postgres (как стандартная от 1С, так и от Постгрес Профешнл бесплатная версия для 1С -- встречал на версиях слона от 9 до 15) в конфигурации БП для Беларуси (на всех версиях с 2017 г. как минимум) на базе размером порядка нескольких Гбайт происходит следующее.

В какой-то момент спонтанно начинает очень долго выполняться запрос остатков по регистру бухгалтерии, если дата взятия остатков больше некоторой фиксированной даты. Например, запрос с виртуальной таблицей ОстаткиИОбороты, где дата начала больше "проблемной даты" или Остатки на дату, большую проблемной. Например, "проблемная дата" 10 мая -- тогда остатки с любой датой до 10 мая будут получаться за 0,5 секунды, а остатки с любой датой 10 мая и позднее -- пару минут.

Лечится с помощью тестирования и исправления -- "Реструктуризация таблиц информационной базы". Естественно, с полной остановкой работы пользователей. Пересчёт итогов или реиндексация таблиц проблему не решают.

Возможно, кто-то знает причину этой проблемы и на основании этой причины мы сможем подобрать операцию, которая бы всё чинила без остановки работы пользователей или же более быстрым способом, нежели полная реструктуризация?
По теме из базы знаний
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
5. Andrekaa 12.06.24 09:44 Сейчас в теме
(1)
(пусть для определённости будет 8.3.22.1750),

После изменения версии платформы запускайте Реструктуризацию. По описанию не понятно на сколько часто вы прыгаете по платформам.
7. ansh15 13.06.24 10:52 Сейчас в теме
(1)
запрос с виртуальной таблицей

PostgreSQL не особенно любит такое, еще, с обсуждением
Попробовать vacuumdb --full имя_базы, затем vacuumdb -j=N --analyze_only имя_базы для обновления статистики, где N число высокопроизводительных ядер, хотя бы 4-8, сколько не жалко. vacuum full многопоточно не выполняется, зато происходит реиндексация таблиц. Все это можно в скрипт и в cron.
Но, в любом случае, от пользователей базу надо будет освободить, установить блокировку регзаданий. чтобы с базой совсем ничего не делалось постороннего. Лучше остановить сервер приложений 1С на это время.. :)
21. paulwist 04.07.24 10:28 Сейчас в теме
2. karamazoff 112 11.06.24 23:20 Сейчас в теме
Вы же написали решение, да платформы нынче кривоватые, может поможет в постгрешке запускать vacuum и reindex по ночам?
3. starik-2005 3060 12.06.24 07:30 Сейчас в теме
А помогает именно рестректуризация, или пересчет остатков тоже помогает? Дата актуальности итогов как-то влияет?
На любой конфигурации дисков? Т.е. локально на SSD и на СХД?
Конфигурация постгреса приводилась в соответствие рекомендациям (и 1С)?
4. karamazoff 112 12.06.24 07:38 Сейчас в теме
ну дык, реиндекс вроде оно? Не думаю, что конфигурация дисков может влиять на данную ситуацию, но идти надо от простого, пробуйте варианты, потом нам расскажете
6. Free_Danial 56 12.06.24 10:14 Сейчас в теме
План проблемного запроса нужен, запрос на sql и 1С, можно долго менять все подряд, но без деталей только догадки.
8. Kernelbug 54 13.06.24 18:04 Сейчас в теме
(5) Не прыгаем по платформам. Не зависит.
Просто спонтанно происходит. Без обновлений, без телодвижений. Через месяц-другой работы. У кого-то реже, у кого-то чаще. У кого-то вообще не происходит. Но периодически встречается у разных клиентов, с разными версиями, базами, платформами. Чётких закономерностей нет.
9. Kernelbug 54 13.06.24 18:05 Сейчас в теме
(7) VACUUM FULL ANALYZE не лечит проблему, это было бы очевидным решением.
10. Kernelbug 54 13.06.24 18:10 Сейчас в теме
(3) Пересчёт остатков без ничего не помогает, ни в режиме пользователя, ни в тестировании-исправлении, требуется именно реструктуризация. Происходит у разнообразных клиентов, и на SSD, и в виртуальных ЦОД с заказанными дисками разного уровня производительности.

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

Да, интересно, что встречалось только на БП для Беларуси и её производных. На КА или ЕРП не сталкивались ни с чем похожим. Так-то разработчики БелБП уже подкидывали нетривиальных багов (решению которых я уже темы посвящал отдельные), но всё же.
11. Kernelbug 54 13.06.24 18:16 Сейчас в теме
(6) Выбрать * из РегистрБухгалтерии.Хозрасчетный.Остатки(&Дата)

Если &Дата больше или равна, скажем 16.04.2024 10:39:46, то запрос выполняется 50-60 секунд. Если дата 16.04.2024 10:39:45 или меньше, то он выполняется секунды 3. Никаких документов на эту дату-время нет, вообще записей в регистре в этом промежутке может не быть.

Отладка усугубляется тем, что проблема проявляется на проде. Выгрузка-загрузка через ДТ или через SQL-дамп порождает уже починенную базу. Клонировать сервер пока не пробовал.

Проблема пользовательская в том, что вот посреди дня база сделала ЁК -- и у всех 20--50 пользователей резко начали тормозить всевозможные выборки, связанные с остатками, коих в базе напихано много даже из коробки: при проведении документов с движением материалов, при открытии форм с подсказками по взаиморасчётам, при открытии отчётов, документов, аналитик. И нужно посередине дня всех выгонять на полчаса либо всем терпеть до вечера.
12. Free_Danial 56 15.06.24 20:27 Сейчас в теме
(11)При спорадической проблеме либо на проде собирать метрики запроса либо точную копию делать, лучше получить точную копию и еще снять метрики после реструктуризации чтоб сравнить можно было, если проблема решается реструктуризацией - то проблему только на sql искать.
13. Kernelbug 54 17.06.24 10:14 Сейчас в теме
(12) Как проводить расследования, если что, это мы знаем. И что проблема где-то в базе. И как метрику снять (в данном случае на глазок 1,5 минуты от 1,5 секунд можно отличить).
Смысл темы в том, чтобы найти кого-то, кто с таким столкнулся, докопался до причины и может поделиться, раньше, чем начинать кучу телодвижений самостоятельно.
Такая проблема может быть не у одного и не у двух, судя даже по нашему кругу клиентов, соответственно, и подробности пригодятся многим.
14. starik-2005 3060 17.06.24 16:37 Сейчас в теме
(13)
кто с таким столкнулся, докопался до причины и может
Имха, кто может, тот тут не сидит. ТоварищЪ Дорошкевич, полагаю, может. Могут в 1С, если туда написать. Но они тту точно не сидят.
Дмитрий74Чел; +1 Ответить
15. Kernelbug 54 18.06.24 17:21 Сейчас в теме
(14) Видете ли, у меня в истории был положительный опыт. Поймали ошибку в БП, отчасти раскопали. Опубликовал тут статью с частичным решением. И на неё пришёл товарищ, фирма которого когда-то тоже столкнулась и раскопала до конца. Решение оказалось элементарным, но совершенно нетривиальным в плане взаимосвязи исходной проблемы и конечного результата.

А если бы не та статья -- был бы у коллеги повод поделиться? Вряд ли, раз уж он сам ничего по своей инициативе не написал. Так что спрашивать всё-таки полезно, сколько потом народу благодарного к нему отметилось.

Я вот если с чем-то необычным или негуглимым столкнулся, считаю себя обязанным об этом написать на тематических ресурсах. Иногда через несколько лет, забыв, нахожу гуглом собственные статьи с решением какой-нибудь неприятной редкой ерунды, опять где-то вылезшей.

Поэтому когда найду конкретное решение -- обязательно об этом напишу. А пока ждём, что кто-то, столкнувшись с тем же самым, поделится решением такой же проблемы. Кто первый, тот и молодец, последующие поколения читателей ему навесят плюсов в карму.
16. starik-2005 3060 18.06.24 17:29 Сейчас в теме
(15)
статью
Статьи читают, форум - вряд ли...
19. Дмитрий74Чел 237 24.06.24 18:21 Сейчас в теме
(11) Я бы все таки ставил на статистику.
Да, вы уже писали про vacuum full. Но вот больше всего похоже на то, что обновление статистики прошло по "недавним" данным, по неполной выборке -и статистика получилась некорректная.
17. user797081 19.06.24 15:09 Сейчас в теме
Как часто регламенты бд проводите?
vacuum analyze ежедневный должен быть
vacuum full хотя бы раз в месяц
настройки autovacuum посмотрите в postgresql.conf, он вообще включен? Должен быть достаточно агрессивный, половина ядер, и чистка таблиц на изменение 10 процентов данных в ней.
Как вариант разнести wal и data по разным дискам, не логическим а именно шпинделям, это связано с особенностью работы ПГ с данными.
18. Kernelbug 54 24.06.24 13:53 Сейчас в теме
(17) Вакуум фулл энэлайз нерегулярный. Но по факту возникновения проблемы он лекарством не является.
Сомневаюсь, что разнесение по разным дискам поможет. Это же не накапливающаяся проблема и не проблема с производительностью базы -- с ней проблем нет. Это некое конкретное нарушение или повреждение в данных, которое логически затрагивает некоторую дату.
Да, речь идёт о совсем небольших базах -- в основном до 10 Гбайт в развёрнутом состоянии.
20. paulwist 25.06.24 09:33 Сейчас в теме
(18)

Вам 2 недели назад написали:

Free_Danial 12.06.24 10:14
План проблемного запроса нужен, запрос на sql и 1С, можно долго менять все подряд, но без деталей только догадки.


Пока гадание продолжается :)
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот