Низкая производительность Postgres
Имеем ситуацию: БП 2.1 на PostgresPro 9.6. Конфа имеет общий реквизит ОбластьДанныхОсновныеДанные.
Откровенно говоря имею слабые познания в области разделения данных, но речь сейчас об этом лишь косвенно.
Ключевым моментом сабжа является то, что при наличии разделения данных по этому реквизиту, например, ПланСчетов (как и остальные объекты) имеет все индексы с первым полем в составе индекса - общий реквизит. Соответственно primarykey таблицы уже не имеют, а кластерный индекс - это ОбщийРеквизит+Ссылка.
При чтении запросом, например, остатка из регистра бухгалтерии в СУБД отправляется запрос, в котором при соединении таблиц условие по ОбщемуРеквизиту указывается не в условии соединения, а в WHERE. Например так:
INNER JOIN _Acc22 T13
ON T13._IDRRef = T2.AccountRRef
WHERE (T13._Fld773 = 0)
При чем это не единичный случай. Очень похоже, что разделитель (первое поле индекса!) в принципе добавляется исключительно в WHERE.
Для MSSQL это не вызывает никаких трудностей, кластерный индекс (_Fld773 + _IDRRef) планировщик задействует, а вот в Постгресе все очень плохо. Пробуешь ручками добавить условие в соединение (ON T13._IDRRef = T2.AccountRRef AND T13._Fld773 = 0) - запрос "выстреливает".
Собственно вопрос к тем кто сталкивался и имеет опыт:
- способен ли PG на некую "адаптацию" к таким запросам? Конфигом тут не отмажешься. Вроде как есть плагины к PG, оптимизирующие планы, и вроде такой "улучшайзер" используется в Энтерпрайз версии PGpro, но дела не имел и не ясно на что эти плагины способны в принципе и на сколько это рисковано в части прочей производительности и сохранения данных?
- есть наиболее понятные способы модификации через 1с (о поддержке речь не идет и разделение не планируется): отключения разделения данных. Т.е. можно удалить разделители, изменить их свойства, влияющие на состав индексов.
Посоветуйте как правильно это сделать???
Проверил следующее: в режиме независимо кластерный индекс ОР+_IDRRef ; в режиме "независимо и совместимо" кластерный остается, но добавляется уникальный некластерный по _IDRRef. Это уже немного радует, но совсем немного.
Еще есть главный вариант - выключить разделение данных в реквизите (полную реструктуризацию сервер потянет). Вопрос что сломается в типовых модулях БСП?? Все ли останется работоспособным?
Варианты создания индексов в СУБД вручную - не вариант. Их нужно добавлять вообще считай в каждый объект. Разработка проекта активная, каждый день могут быть обновления. Да и почти удвоить количество индексов придется.
PS: остается, пока слабо меня интересующий, но все же вопрос: как же справляться с подобной ситуацией на поддержке или с необходимостью разделения данных?
UP: в ходе тестирования выяснилось, что все не совсем так, как я предполагал. Шапку редактировать не стал. Обо всем ниже в постах.
Откровенно говоря имею слабые познания в области разделения данных, но речь сейчас об этом лишь косвенно.
Ключевым моментом сабжа является то, что при наличии разделения данных по этому реквизиту, например, ПланСчетов (как и остальные объекты) имеет все индексы с первым полем в составе индекса - общий реквизит. Соответственно primarykey таблицы уже не имеют, а кластерный индекс - это ОбщийРеквизит+Ссылка.
При чтении запросом, например, остатка из регистра бухгалтерии в СУБД отправляется запрос, в котором при соединении таблиц условие по ОбщемуРеквизиту указывается не в условии соединения, а в WHERE. Например так:
INNER JOIN _Acc22 T13
ON T13._IDRRef = T2.AccountRRef
WHERE (T13._Fld773 = 0)
При чем это не единичный случай. Очень похоже, что разделитель (первое поле индекса!) в принципе добавляется исключительно в WHERE.
Для MSSQL это не вызывает никаких трудностей, кластерный индекс (_Fld773 + _IDRRef) планировщик задействует, а вот в Постгресе все очень плохо. Пробуешь ручками добавить условие в соединение (ON T13._IDRRef = T2.AccountRRef AND T13._Fld773 = 0) - запрос "выстреливает".
Собственно вопрос к тем кто сталкивался и имеет опыт:
- способен ли PG на некую "адаптацию" к таким запросам? Конфигом тут не отмажешься. Вроде как есть плагины к PG, оптимизирующие планы, и вроде такой "улучшайзер" используется в Энтерпрайз версии PGpro, но дела не имел и не ясно на что эти плагины способны в принципе и на сколько это рисковано в части прочей производительности и сохранения данных?
- есть наиболее понятные способы модификации через 1с (о поддержке речь не идет и разделение не планируется): отключения разделения данных. Т.е. можно удалить разделители, изменить их свойства, влияющие на состав индексов.
Посоветуйте как правильно это сделать???
Проверил следующее: в режиме независимо кластерный индекс ОР+_IDRRef ; в режиме "независимо и совместимо" кластерный остается, но добавляется уникальный некластерный по _IDRRef. Это уже немного радует, но совсем немного.
Еще есть главный вариант - выключить разделение данных в реквизите (полную реструктуризацию сервер потянет). Вопрос что сломается в типовых модулях БСП?? Все ли останется работоспособным?
Варианты создания индексов в СУБД вручную - не вариант. Их нужно добавлять вообще считай в каждый объект. Разработка проекта активная, каждый день могут быть обновления. Да и почти удвоить количество индексов придется.
PS: остается, пока слабо меня интересующий, но все же вопрос: как же справляться с подобной ситуацией на поддержке или с необходимостью разделения данных?
UP: в ходе тестирования выяснилось, что все не совсем так, как я предполагал. Шапку редактировать не стал. Обо всем ниже в постах.
По теме из базы знаний
- Практика перехода на Linux и Postgres в небольшой компании (10 пользователей)
- Настройка параметров ядра Linux для оптимизации PostgreSQL
- Настройка параметров PostgreSQL для оптимизации производительности
- Простое обнаружение проблем производительности в PostgreSQL
- Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Что-то около 3 секунды против 0,9 сек.
База не бог весть какая объемная, но плохие планы начали ощущаться.
Сейчас переключил общий реквизит в "не разделять" - картинка на данном соединении улучшилась, но изменилась в худшую сторону в других местах... Попытка изменять варианты соединений (Nestloop, merge и т.д.) погоду не меняют.
База не бог весть какая объемная, но плохие планы начали ощущаться.
Сейчас переключил общий реквизит в "не разделять" - картинка на данном соединении улучшилась, но изменилась в худшую сторону в других местах... Попытка изменять варианты соединений (Nestloop, merge и т.д.) погоду не меняют.
(3) можно попытаться снизить стоимость операций чтения с диска, что заставит оптимизатор постгреса интенсивнее работать с индексами. Также предлагаю кластеризовать соответствующие таблицы, ибо в постгресе нет как такового кластерного индекса - просто по этим полям происходит кластеризация таблицы, при этом новые записи не падают в таблицу в указанном в кластерном индексе порядке. Фактически в MS SQL положение лучше благодаря попытке системы поддерживать структуру таблицы в соответствии с кластерным индексом, но при большом разнообразии данных в INSERT без реструктуризации индексов тоже через какое-то время все начинает лагать, просто объем данных, на котором лаги чувствительны, гораздо выше.
В целом по подобной ситуации хотел высказаться.
Ведь подобного рода запрос предполагает, что первично соединение, вторично условие where. Если не полагаться на "прозорливость" оптимизаторов, то подобный запрос априори не должен использовать индекс... Так? Это похоже на прокол разработчиков платформы. Было бы добавлено условие в соединение - не возникло бы сомнений в использовании индекса в любой СУБД.
Может имеет смысл написать в багрепорт?
Ведь подобного рода запрос предполагает, что первично соединение, вторично условие where. Если не полагаться на "прозорливость" оптимизаторов, то подобный запрос априори не должен использовать индекс... Так? Это похоже на прокол разработчиков платформы. Было бы добавлено условие в соединение - не возникло бы сомнений в использовании индекса в любой СУБД.
Может имеет смысл написать в багрепорт?
Много всего перелопатил за последние дни в части тестирования запроса получения остатков. Частный запрос, но очень часто повторяемый. Поэтому и уделил ему особое внимание. Кстати замечу еще, что остаток получался на 04-е число августа. На какое-нибудь 25-е все в разы быстрее ))) Это было ожидаемо, т.к. тормозила именно выборка с конца месяца.
Тестировал на 4-5 базах одновременно + MS + PGpro + PS(9.6.3-3.1 c сайта 1с)
Разницы между версиями PG не замечено вообще.
(7)
Читаю:
PS: а еще узнал, что PGadmin показывает время не выполнения запроса, а время с выводом на экран (( А я ему доверял. Поэтому смотреть время только в EXPLAIN ANALYSE (TIMING). Консоли 1с в этом плане правдивее. И очень любопытно то, что в 1с запрос выполняется быстрее чем в pgadmin даже при разборе плана. В 1с 0.8-1.0 сек!! против 1.1-1.2. Разница весьма заметна, не понятно почему.
Тестировал на 4-5 базах одновременно + MS + PGpro + PS(9.6.3-3.1 c сайта 1с)
Разницы между версиями PG не замечено вообще.
первично соединение, вторично условие where
Похоже я здесь для себя открыл америку. Судя по планам (если конечно же я верно их трактую), прежде чем соединить выборки, СУБД накладывают возможные условия. Т.е. сначала выполняют WHERE (поиск в индексе), а только потом Join (nested loops).
(7)
Можно enable_sqescan в off установить и посмотреть, меняется ли что-нибудь.
В точку. Что-то я полез в COSTы и упустил из виду совет. Начал все подряд менять в надежде получить изменения во времени. Именно на этом параметре и получил положительный результат. Время упало с 2,5-2,8 сек до 1.1-1.2 сек.
Читаю:
Включает или отключает использование планировщиком планов последовательного сканирования.
Т.е. самостоятельно по предполагаемой стоимости выполнения запроса PG не может определить, что полное сканирование будет плохим методом. Может определять это, но не всегда? Или вообще не умеет этого делать???
PS: а еще узнал, что PGadmin показывает время не выполнения запроса, а время с выводом на экран (( А я ему доверял. Поэтому смотреть время только в EXPLAIN ANALYSE (TIMING). Консоли 1с в этом плане правдивее. И очень любопытно то, что в 1с запрос выполняется быстрее чем в pgadmin даже при разборе плана. В 1с 0.8-1.0 сек!! против 1.1-1.2. Разница весьма заметна, не понятно почему.
(6) На users.v8.1c.ru, в августе, была выложена тестовая 9.6.3-2.1C, в особенностях релиза которой сообщалось, что "изменен алгоритм работы планировщика запросов", в результате чего "планы запросов выбираются более эффективно" и "в определенных сценариях со сложными запросами" можно наблюдать существенное ускорение их выполнения.
Потом она плавно перешла в актуальную версию с нумерацией релиза 9.6.3-3.1C.
Можно ее попробовать. У нас, в частности, время формирования отчета "Ведомость ОС, НМА"(БГУ) уменьшилось с полутора минут(на предыдущих версиях Pg) до 18 сек, при enable_nestloop=on
Потом она плавно перешла в актуальную версию с нумерацией релиза 9.6.3-3.1C.
Можно ее попробовать. У нас, в частности, время формирования отчета "Ведомость ОС, НМА"(БГУ) уменьшилось с полутора минут(на предыдущих версиях Pg) до 18 сек, при enable_nestloop=on
(8)
Не обладаю опытом что из версий слона лучше, но повелся на слух, то PGpro для 1с работает веселее. С ней и мучаюсь.
Что ж... Поставим с сайта 1с, оценим.
"изменен алгоритм работы планировщика запросов"
Релиз вижу, но откуда такая информация? В описании особенностей релиза про это молчок.
Не обладаю опытом что из версий слона лучше, но повелся на слух, то PGpro для 1с работает веселее. С ней и мучаюсь.
Что ж... Поставим с сайта 1с, оценим.
enable_nestloop=on
в смысле по дефолту? Если параметр отключен, то вроде как ON ??
(9)
Да. При enable_nestloop=off - меньше секунды на любой версии.
В особенностях релиза тестовой 9.6.3-2.1C и было. В актуальной почему-то решили не указывать...
в смысле по дефолту?
Да. При enable_nestloop=off - меньше секунды на любой версии.
Релиз вижу, но откуда такая информация? В описании особенностей релиза про это молчок.
В особенностях релиза тестовой 9.6.3-2.1C и было. В актуальной почему-то решили не указывать...
Интересная тема.
В особенностях релиза PostgreSQL, версия 9.6.3-3.1С,
указано
"Поддержка этой версии в 1С:Предприятии 8.3 реализована в версии 8.3.10 и старше."
У нас работают как 8.3 так и 8.2. под PostgreSQL.
Можно ли это релиз PostgreSQL, версия 9.6.3-3.1С устанавливать в нашем случае?
В особенностях релиза PostgreSQL, версия 9.6.3-3.1С,
указано
"Поддержка этой версии в 1С:Предприятии 8.3 реализована в версии 8.3.10 и старше."
У нас работают как 8.3 так и 8.2. под PostgreSQL.
Можно ли это релиз PostgreSQL, версия 9.6.3-3.1С устанавливать в нашем случае?
(13)
На одном экземпляре PostgreSQL работать и в 8.2 и в 8.3 не получится. Нужно будет два экзепляра - один, собранный с integer_datetimes=off, для 8.2, другой, собранный с integer_datetimes=on, для 8.3.
Или переводить все конфигурации на 8.3.
Для использования PostgreSQL 9.6.3-3.1C с версиями 1С:Предприятия ниже 8.3.10 необходимо его собрать с установленным значением параметра integer_datetimes=off
- оттуда же.
На одном экземпляре PostgreSQL работать и в 8.2 и в 8.3 не получится. Нужно будет два экзепляра - один, собранный с integer_datetimes=off, для 8.2, другой, собранный с integer_datetimes=on, для 8.3.
Или переводить все конфигурации на 8.3.
(16)В свое время на ней и 1С 8.2 работали, каких-то серьезных проблем и ошибок замечено не было. Был(как помнится) момент, если загружать dt-файл в не пустую базу, то даже на небольших базах(5-10 ГБ) процесс мог длиться минут 15-20, В пустую же базу dt загружался весьма быстро. При работе с последующими версиями PostgreSQL такого уже не наблюдалось.
(15)
Спасибо за ответ!
Подскажите, пожалуйста,
2 экземпляра -
это значит установить еще одни новый PostGree на новый порт и к нему подключить базы 8.3, базы 8.2 оставить у прежнего PostGree
или
установить новый PostGree, старый убрать, к новому подключить все базы,
но вызывать каким-то образом 2 службы с разными параметрами?
Спасибо за ответ!
Подскажите, пожалуйста,
2 экземпляра -
это значит установить еще одни новый PostGree на новый порт и к нему подключить базы 8.3, базы 8.2 оставить у прежнего PostGree
или
установить новый PostGree, старый убрать, к новому подключить все базы,
но вызывать каким-то образом 2 службы с разными параметрами?
Вроде все еще грустнее.
Я не настоящий сварщик, но ЕМНИП в postgresql вообще нет кластерных индексов в понимании MSSQL (есть только разовые операции упорядочивания данных таблицы по "кластерному" индексу).
Т.е. даже при удачном фуллскане по якобы кластеризованному индексу, при необходимости доступа к полям не указанным в индексе - будут дополнительные расходы, в отличие от MSSQL.
Я не настоящий сварщик, но ЕМНИП в postgresql вообще нет кластерных индексов в понимании MSSQL (есть только разовые операции упорядочивания данных таблицы по "кластерному" индексу).
Т.е. даже при удачном фуллскане по якобы кластеризованному индексу, при необходимости доступа к полям не указанным в индексе - будут дополнительные расходы, в отличие от MSSQL.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот