Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
(0)Руслан, добрый день
Согласно документации: Значение имеют только их отношения, поэтому умножение или деление всех переменных на один коэффициент никак не повлияет на выбор планировщика. По умолчанию эти переменные определяются относительно стоимости чтения последовательной страницы: то есть, переменную seq_page_cost удобно задать равной 1.0, а все другие переменные стоимости определить относительно неё
По умолчанию:
seq_page_cost = 1
random_page_cost = 4
У Вас:
seq_page_cost = 0.1
random_page_cost = 0.4
Т.е. это точно не повлияло на выбор планировщика.
А вот: cpu_operator_cost вы уменьшили в 10 раз, скорее всего именно это дало такой эффект.
effective_cache_size = 12GB, тут тоже эффект положительный, так как по умолчанию скорее всего было 4GB, а при наличии у сервера 32GB оптимальное значение как раз 12-16GB
Если есть желание, попробуйте вернуть параметры seq_page_cost = 1 и random_page_cost = 4 и посмотреть на поведение системы.
Выдержка из документации 1с ( ):
При выполнения некоторых регламентных операций (Закрытие месяца, Расчет себестоимости и т.п), где используются сложные запросы с большим количеством соединений больших таблиц, возможно существенное увеличение времени выполнения операции. В основном, эти проблемы связаны с работой оптимизатора PostgreSQL и отсутствием актуальной статистики по таблицам, учавствующим в запросе.
Варианты решения проблемы:
…
Отключение оптимизатору возможности использования NESTED LOOP при выборе плана выполнения запроса в конфигурации PostgreSQL:
Файл postgresql.conf — enable_nestloop=off.
Отрицательным эффектом этого способа является возможное замедление некоторых запросов, поскольку при их выполнении будут использоваться другие, более затратные, методы соединения (HASH JOIN).
…
Изменение параметров настройки оптимизатора:
Файл postgresql.conf:
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025
Показать
(2)
Я также сначала думал, поэтому первоначально и не изменял их, но оказалось что установка именно отношения 0.1/0.4 приводит к выбору оптимального плана. Думаю тут дело в том, что в секции «Planner Cost Constants» есть и другие настройки, и устанавливая seq_page_cost в 0.1 мы автоматом увеличиваем стоимость остальных в 10 раз, а значения random_page_cost фактически возвращаем в исходное.
(4)Ну да, только установка enable_nestloop=off приводит к замедлению многих других запросов. Оно вроде небольшое, но в итоге база даных вращается достаточно вяло.
Смысл статьи в том, что возможно настроить выбор оптимального плана не отключая nestloop. Ну и еще запрос конечно — достаточно удачно получилось, что проблему можно воспроизвести на простеньком запросе. Это ведь практически готовый тестовый пример.
(4) Сначала покажите, что
, тогда сможете воспользоваться вариантом решения из документации. ))
Попробуйте делать запросы для валютных и не валютных счетов отдельно, затем ОБЪЕДИНИТЬ ВСЕ результаты запросов. А то из-за пары валютных счетов очень много возни: null, сортировка и т.д.
Попробуйте убрать «Для изменения», замерить скорость и вернуть. Обязательно вернуть ))
(7) «Для изменения» у меня также был главный подозреваемый ) Но проблема оказалась все-таки не в нем а в том, что Период принимал значение момента времени и построитель выбирал неоптимальный план исполнения. Переделать запрос было можно — вариант с получением остатка на время перед документом и объединением с оборотами между этим временем и позицией документа, исполнялся нормально (0.5с). Но представленный в статье вариант получился все-таки быстрее (0.3с), да и несомненный плюс что не пришлось изменять модуль на поддержке.
Кстати, уже когда публиковал статью — встретил информацию что подобная проблема с запросами по позиции документа наблюдается также и в MS SQL:
(3) Т.е. для вас проще снять конфигурацию с поддержки, переписать запрос, затем следить за его сохранность от релиза к релизу… вместо тюнинга параметров в конфиге?