Резкое замедление операции взятия остатков по регистру бухгалтерии, начиная с некоторой даты
Доброго вечера, коллеги.
Возможно, кто-то расскажет, что находится "под капотом" у следующей проблемы и как её можно победить непрямыми методами.
Суть: на разных платформах, как минимум начиная с 8.3.20 (пусть для определённости будет 8.3.22.1750), на разных ОС (и Виндовс, и Линукс) на СУБД Postgres (как стандартная от 1С, так и от Постгрес Профешнл бесплатная версия для 1С -- встречал на версиях слона от 9 до 15) в конфигурации БП для Беларуси (на всех версиях с 2017 г. как минимум) на базе размером порядка нескольких Гбайт происходит следующее.
В какой-то момент спонтанно начинает очень долго выполняться запрос остатков по регистру бухгалтерии, если дата взятия остатков больше некоторой фиксированной даты. Например, запрос с виртуальной таблицей ОстаткиИОбороты, где дата начала больше "проблемной даты" или Остатки на дату, большую проблемной. Например, "проблемная дата" 10 мая -- тогда остатки с любой датой до 10 мая будут получаться за 0,5 секунды, а остатки с любой датой 10 мая и позднее -- пару минут.
Лечится с помощью тестирования и исправления -- "Реструктуризация таблиц информационной базы". Естественно, с полной остановкой работы пользователей. Пересчёт итогов или реиндексация таблиц проблему не решают.
Возможно, кто-то знает причину этой проблемы и на основании этой причины мы сможем подобрать операцию, которая бы всё чинила без остановки работы пользователей или же более быстрым способом, нежели полная реструктуризация?
Возможно, кто-то расскажет, что находится "под капотом" у следующей проблемы и как её можно победить непрямыми методами.
Суть: на разных платформах, как минимум начиная с 8.3.20 (пусть для определённости будет 8.3.22.1750), на разных ОС (и Виндовс, и Линукс) на СУБД Postgres (как стандартная от 1С, так и от Постгрес Профешнл бесплатная версия для 1С -- встречал на версиях слона от 9 до 15) в конфигурации БП для Беларуси (на всех версиях с 2017 г. как минимум) на базе размером порядка нескольких Гбайт происходит следующее.
В какой-то момент спонтанно начинает очень долго выполняться запрос остатков по регистру бухгалтерии, если дата взятия остатков больше некоторой фиксированной даты. Например, запрос с виртуальной таблицей ОстаткиИОбороты, где дата начала больше "проблемной даты" или Остатки на дату, большую проблемной. Например, "проблемная дата" 10 мая -- тогда остатки с любой датой до 10 мая будут получаться за 0,5 секунды, а остатки с любой датой 10 мая и позднее -- пару минут.
Лечится с помощью тестирования и исправления -- "Реструктуризация таблиц информационной базы". Естественно, с полной остановкой работы пользователей. Пересчёт итогов или реиндексация таблиц проблему не решают.
Возможно, кто-то знает причину этой проблемы и на основании этой причины мы сможем подобрать операцию, которая бы всё чинила без остановки работы пользователей или же более быстрым способом, нежели полная реструктуризация?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
PostgreSQL такое,
Попробовать vacuumdb --full имя_базы, затем vacuumdb -j=N --analyze_only имя_базы для обновления статистики, где N число высокопроизводительных ядер, хотя бы 4-8, сколько не жалко. vacuum full многопоточно не выполняется, зато происходит реиндексация таблиц. Все это можно в скрипт и в cron.
Но, в любом случае, от пользователей базу надо будет освободить, установить блокировку регзаданий. чтобы с базой совсем ничего не делалось постороннего. Лучше остановить сервер приложений 1С на это время.. :)
запрос с виртуальной таблицей
PostgreSQL такое,
Попробовать vacuumdb --full имя_базы, затем vacuumdb -j=N --analyze_only имя_базы для обновления статистики, где N число высокопроизводительных ядер, хотя бы 4-8, сколько не жалко. vacuum full многопоточно не выполняется, зато происходит реиндексация таблиц. Все это можно в скрипт и в cron.
Но, в любом случае, от пользователей базу надо будет освободить, установить блокировку регзаданий. чтобы с базой совсем ничего не делалось постороннего. Лучше остановить сервер приложений 1С на это время.. :)
А помогает именно рестректуризация, или пересчет остатков тоже помогает? Дата актуальности итогов как-то влияет?
На любой конфигурации дисков? Т.е. локально на SSD и на СХД?
Конфигурация постгреса приводилась в соответствие (и 1С)?
На любой конфигурации дисков? Т.е. локально на SSD и на СХД?
Конфигурация постгреса приводилась в соответствие (и 1С)?
(5) Не прыгаем по платформам. Не зависит.
Просто спонтанно происходит. Без обновлений, без телодвижений. Через месяц-другой работы. У кого-то реже, у кого-то чаще. У кого-то вообще не происходит. Но периодически встречается у разных клиентов, с разными версиями, базами, платформами. Чётких закономерностей нет.
Просто спонтанно происходит. Без обновлений, без телодвижений. Через месяц-другой работы. У кого-то реже, у кого-то чаще. У кого-то вообще не происходит. Но периодически встречается у разных клиентов, с разными версиями, базами, платформами. Чётких закономерностей нет.
(3) Пересчёт остатков без ничего не помогает, ни в режиме пользователя, ни в тестировании-исправлении, требуется именно реструктуризация. Происходит у разнообразных клиентов, и на SSD, и в виртуальных ЦОД с заказанными дисками разного уровня производительности.
Причём ломается запрос остатков с конкретной даты. Есть некоторые мысли насчёт того, что или какие-то файлы данных Постгри фрагментируются нерациональным образом -- или индексные, или файлы данных, связанные с таблицами остатков. Но вариантов и идей очень много, хотелось бы сузить поле возможностей.
Да, интересно, что встречалось только на БП для Беларуси и её производных. На КА или ЕРП не сталкивались ни с чем похожим. Так-то разработчики БелБП уже подкидывали нетривиальных багов (решению которых я уже темы посвящал отдельные), но всё же.
Причём ломается запрос остатков с конкретной даты. Есть некоторые мысли насчёт того, что или какие-то файлы данных Постгри фрагментируются нерациональным образом -- или индексные, или файлы данных, связанные с таблицами остатков. Но вариантов и идей очень много, хотелось бы сузить поле возможностей.
Да, интересно, что встречалось только на БП для Беларуси и её производных. На КА или ЕРП не сталкивались ни с чем похожим. Так-то разработчики БелБП уже подкидывали нетривиальных багов (решению которых я уже темы посвящал отдельные), но всё же.
(6) Выбрать * из РегистрБухгалтерии.Хозрасчетный.Остатки(&Дата)
Если &Дата больше или равна, скажем 16.04.2024 10:39:46, то запрос выполняется 50-60 секунд. Если дата 16.04.2024 10:39:45 или меньше, то он выполняется секунды 3. Никаких документов на эту дату-время нет, вообще записей в регистре в этом промежутке может не быть.
Отладка усугубляется тем, что проблема проявляется на проде. Выгрузка-загрузка через ДТ или через SQL-дамп порождает уже починенную базу. Клонировать сервер пока не пробовал.
Проблема пользовательская в том, что вот посреди дня база сделала ЁК -- и у всех 20--50 пользователей резко начали тормозить всевозможные выборки, связанные с остатками, коих в базе напихано много даже из коробки: при проведении документов с движением материалов, при открытии форм с подсказками по взаиморасчётам, при открытии отчётов, документов, аналитик. И нужно посередине дня всех выгонять на полчаса либо всем терпеть до вечера.
Если &Дата больше или равна, скажем 16.04.2024 10:39:46, то запрос выполняется 50-60 секунд. Если дата 16.04.2024 10:39:45 или меньше, то он выполняется секунды 3. Никаких документов на эту дату-время нет, вообще записей в регистре в этом промежутке может не быть.
Отладка усугубляется тем, что проблема проявляется на проде. Выгрузка-загрузка через ДТ или через SQL-дамп порождает уже починенную базу. Клонировать сервер пока не пробовал.
Проблема пользовательская в том, что вот посреди дня база сделала ЁК -- и у всех 20--50 пользователей резко начали тормозить всевозможные выборки, связанные с остатками, коих в базе напихано много даже из коробки: при проведении документов с движением материалов, при открытии форм с подсказками по взаиморасчётам, при открытии отчётов, документов, аналитик. И нужно посередине дня всех выгонять на полчаса либо всем терпеть до вечера.
(11)При спорадической проблеме либо на проде собирать метрики запроса либо точную копию делать, лучше получить точную копию и еще снять метрики после реструктуризации чтоб сравнить можно было, если проблема решается реструктуризацией - то проблему только на sql искать.
(12) Как проводить расследования, если что, это мы знаем. И что проблема где-то в базе. И как метрику снять (в данном случае на глазок 1,5 минуты от 1,5 секунд можно отличить).
Смысл темы в том, чтобы найти кого-то, кто с таким столкнулся, докопался до причины и может поделиться, раньше, чем начинать кучу телодвижений самостоятельно.
Такая проблема может быть не у одного и не у двух, судя даже по нашему кругу клиентов, соответственно, и подробности пригодятся многим.
Смысл темы в том, чтобы найти кого-то, кто с таким столкнулся, докопался до причины и может поделиться, раньше, чем начинать кучу телодвижений самостоятельно.
Такая проблема может быть не у одного и не у двух, судя даже по нашему кругу клиентов, соответственно, и подробности пригодятся многим.
(14) Видете ли, у меня в истории был положительный опыт. Поймали ошибку в БП, отчасти раскопали. Опубликовал тут статью с частичным решением. И на неё пришёл товарищ, фирма которого когда-то тоже столкнулась и раскопала до конца. Решение оказалось элементарным, но совершенно нетривиальным в плане взаимосвязи исходной проблемы и конечного результата.
А если бы не та статья -- был бы у коллеги повод поделиться? Вряд ли, раз уж он сам ничего по своей инициативе не написал. Так что спрашивать всё-таки полезно, сколько потом народу благодарного к нему отметилось.
Я вот если с чем-то необычным или негуглимым столкнулся, считаю себя обязанным об этом написать на тематических ресурсах. Иногда через несколько лет, забыв, нахожу гуглом собственные статьи с решением какой-нибудь неприятной редкой ерунды, опять где-то вылезшей.
Поэтому когда найду конкретное решение -- обязательно об этом напишу. А пока ждём, что кто-то, столкнувшись с тем же самым, поделится решением такой же проблемы. Кто первый, тот и молодец, последующие поколения читателей ему навесят плюсов в карму.
А если бы не та статья -- был бы у коллеги повод поделиться? Вряд ли, раз уж он сам ничего по своей инициативе не написал. Так что спрашивать всё-таки полезно, сколько потом народу благодарного к нему отметилось.
Я вот если с чем-то необычным или негуглимым столкнулся, считаю себя обязанным об этом написать на тематических ресурсах. Иногда через несколько лет, забыв, нахожу гуглом собственные статьи с решением какой-нибудь неприятной редкой ерунды, опять где-то вылезшей.
Поэтому когда найду конкретное решение -- обязательно об этом напишу. А пока ждём, что кто-то, столкнувшись с тем же самым, поделится решением такой же проблемы. Кто первый, тот и молодец, последующие поколения читателей ему навесят плюсов в карму.
Как часто регламенты бд проводите?
vacuum analyze ежедневный должен быть
vacuum full хотя бы раз в месяц
настройки autovacuum посмотрите в postgresql.conf, он вообще включен? Должен быть достаточно агрессивный, половина ядер, и чистка таблиц на изменение 10 процентов данных в ней.
Как вариант разнести wal и data по разным дискам, не логическим а именно шпинделям, это связано с особенностью работы ПГ с данными.
vacuum analyze ежедневный должен быть
vacuum full хотя бы раз в месяц
настройки autovacuum посмотрите в postgresql.conf, он вообще включен? Должен быть достаточно агрессивный, половина ядер, и чистка таблиц на изменение 10 процентов данных в ней.
Как вариант разнести wal и data по разным дискам, не логическим а именно шпинделям, это связано с особенностью работы ПГ с данными.
(17) Вакуум фулл энэлайз нерегулярный. Но по факту возникновения проблемы он лекарством не является.
Сомневаюсь, что разнесение по разным дискам поможет. Это же не накапливающаяся проблема и не проблема с производительностью базы -- с ней проблем нет. Это некое конкретное нарушение или повреждение в данных, которое логически затрагивает некоторую дату.
Да, речь идёт о совсем небольших базах -- в основном до 10 Гбайт в развёрнутом состоянии.
Сомневаюсь, что разнесение по разным дискам поможет. Это же не накапливающаяся проблема и не проблема с производительностью базы -- с ней проблем нет. Это некое конкретное нарушение или повреждение в данных, которое логически затрагивает некоторую дату.
Да, речь идёт о совсем небольших базах -- в основном до 10 Гбайт в развёрнутом состоянии.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот