Postgres Отличающиеся планы запросов Prod / QA

Question

У меня есть два сервера баз данных, которые оба находятся в «тестовом» режиме, причем один из них должен быть переведен на рабочий сервер.Таким образом, спецификации различаются и в некоторых конфигурациях, но мы обнаруживаем, что сервер с недостаточной мощностью создает лучшие планы запросов и, следовательно, более быстрые запросы.

Статистика :

Обе системы имеют примерно одинаковые данные, и их количество выглядит следующим образом:

Size     |  Part
--------------------
1.47 TB  |  Entire DB
871 GB   |  Tables
635 GB   |  Indexes

У большего сервера базы данных есть следующие характеристики:

Оперативная память: 500 ГБ

Процессор:16 ядер 2,0 ГГц Intel

Использование твердотельных накопителей

Postgres 10,0

Memlock настроен на резервирование 485 ГБ специально для Postgres

Параметры Postgres:

shared_buffers: 125 ГБ

work_mem: 36 МБ

effective_cache_size: 300 ГБ

random_page_cost: 1

default_statistics_target: 1000

План запроса: https://explain.depesz.com/s/9Ww6

Меньший сервер имеет следующую статистику:

Оперативная память: 281 ГБ

Процессор: 4 ядра 2.0ГГц Intel

Использование твердотельных накопителей

Postgres 10,0

Memlock настроен на резервирование 240 ГБ специально для Postgres

Параметры Postgres:

shared_buffers: 50 ГБ

work_mem: 25,6 МБ

effective_cache_size: 150 ГБ

random_page_cost: 4

default_statistics_target: 100

План запроса: https://explain.depesz.com/s/4WUH

Мы попытались переключить random_page_cost, статистику по умолчанию (с последующим анализом) и рабочую память, чтобы они соответствовали друг другу.Наибольший выигрыш был получен после выполнения vacuum full для всех таблиц в запросе.

Рабочая нагрузка: этот компьютер является репликой чтения, используемой для извлечения файлов данных в виде файлов XML и т. Д. Таким образом, он получает реплицированные данные иимеет довольно большую нагрузку на чтение.

Вопрос: Что мне нужно искать, чтобы сделать этот запрос более производительным на большом сервере, где он работает медленнее?В идеале этот запрос выполняется намного быстрее, чем на меньшем сервере.Похоже, что после масштабирования мы не смогли правильно настроить параметры, чтобы использовать преимущества нашего оборудования.Должно быть, я что-то упускаю из виду.

Редактировать: Я выдвигал необъяснимые планы.Я также пытался увеличить статистику до 3000 с 1000, и это не помогло планам.То же самое касается изменения random_page_cost для соответствия между серверами.

Answer 1

Конфигурация PostgreSQL на двух машинах совершенно различна, поэтому неудивительно, что планы запросов различны.Особенно большое значение имеет random_page_cost.

Вы определенно должны сравнить свою рабочую нагрузку с различными настройками shared_buffers: у вас, вероятно, слишком много (обычно это 8 ГБ).

Но яподумайте, что оба ваши планы запросов ужасны, и ваша проблема в другом месте.

Оптимизатор неверно оценивает количество строк, возвращаемых при сканировании индекса на showtimes.mappable_program, и это неверноприводит к еще худшим ошибкам и неправильному выбору плана позже.

Попробуйте увеличить плотность статистики в столбце:

ALTER TABLE showtimes.mappable_program ALTER mapping_scheme_id
   SET STATISTICS 1000;

Затем ANALYZE таблица.

Если это не помогает, измените запрос, заменив

WHERE COALESCE(mp2.ignore::integer, 0) = 0

на

WHERE mp2.ignore = '0' OR mp2.ignore IS NULL

. Это может помочь оптимизатору лучше оценить условие.