Проблема производительности PostgreSQL

Question

Я вижу в журналах postgresql, что выполнение некоторых простых запросов (без объединений и с использованием только условий сопоставления, использующих индексы) занимает от 1 до 3 секунд. Я регистрирую запросы, которые выполняются дольше, чем секунда, поэтому есть похожие запросы, которые выполняются за секунду, о которых не сообщается.

Когда я пытаюсь выполнить тот же запрос с помощью EXPLAIN ANALYZE, это занимает несколько миллисекунд.

Таблица содержит около 8 миллионов записей, и в нее часто пишут и запрашивают. Я включил автоматический вакуум и даже недавно (несколько часов назад) провел ВАКУУМНЫЙ АНАЛИЗ на этом столе.

Пример записи в журнале запросов: 30 дек. 10:14:57 db01 postgres [7400]: [20-1] LOG: длительность: 3857,322 мс Оператор: SELECT * FROM "отклики" WHERE ("отклики" .contest_id = 17469) И (user_id нет 30 дек. 10:14:57 db01 postgres [7400]: [20-2] null) ORDER BY updated_on desc LIMIT 5

test_id и user_id проиндексированы. updated_on не индексируется. Если я его индексирую, планировщик запросов игнорирует индекс Compet_id и использует вместо него updated_on, что еще больше замедляет запрос. Максимальное количество записей в вышеупомянутом запросе без LIMIT не должно превышать 1000.

Любая помощь будет высоко ценится.

Answer 1

Здесь могут быть полезны некоторые подробности, в зависимости от того, можете ли вы их предоставить. Наиболее полезным будет фактический вывод вашего EXPLAIN ANALYZE, чтобы мы могли видеть, что он делает при выполнении запроса. Определение запрашиваемой таблицы также может оказаться полезным, наряду с индексами. Чем больше информации, тем лучше. Сейчас я могу только строить догадки о том, что происходит, вот несколько слепых ударов:

• В этой базе данных одновременно происходит множество других операций SELECT, и периодически данные и / или результаты истекают из некоторого кеша.
• Есть что-то еще, что периодически блокирует эту таблицу на 3-4 секунды, прежде чем снова ее отпустить, и в этот момент этот запрос зависает
• Эта таблица записана в настолько , что статистика таблицы в итоге почти никогда не отражает реальность, и поэтому анализатор запросов ошибочно принимает решение о том, использовать или нет индексы для выполнения запроса .

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

Answer 2

• замок
• подкачка
• CLUSTER / VACUUM FULL в задании cron
• насыщенная сеть
• насыщенный IO

проверить iostat, vmstat, iptraf ...

Answer 3

если точно такой же запрос занимает миллисекунды при анализе объяснения и 3 секунды в журналах (т.е. я предполагаю, что это происходит за 3 секунды, а не каждый вызов так долго), - это определенно означает, что проблема блокировки .

Answer 4

pgsql-performance - отличный список рассылки для вопросов такого рода.

Кажется, у вас есть две проблемы:

1) Вы хотите иметь возможность индексировать updated_on, но если вы это сделаете, PostgreSQL выбирает неправильный план.

Мое первое сомнение заключается в том, что PostgreSQL переоценивает количество кортежей, соответствующих предикату "(responses.contest_id = 17469) AND (user_id is not null)". Если postgres сначала использует этот предикат, он должен позже отсортировать значения для реализации ORDER BY. Вы говорите, что это соответствует 1000 кортежей; если postgresql считает, что он соответствует 100000, возможно, он считает, что сканирование по порядку с использованием индекса updated_on будет дешевле. Другим фактором может быть ваша конфигурация: если значение work_mem установлено на низком уровне, может показаться, что сортировка обходится дороже, чем она есть.

Вам действительно нужно показать вывод EXPLAIN ANALYZE медленного запроса, чтобы мы могли понять, почему он может выбирать сканирование индекса для updated_on.

2) Даже если он не проиндексирован, иногда требуется некоторое время для выполнения, но вы не знаете почему, потому что, если вы запускаете его вручную, он работает нормально.

Используйте модуль auto_explain contrib, новый с 8.4. Это позволяет вам регистрировать вывод EXPLAIN ANALYZE запросов, которые занимают слишком много времени. Простая регистрация запроса ставит вас именно в ту проблему, с которой вы сейчас сталкиваетесь: каждый раз, когда вы запускаете запрос, это быстро.

Answer 5

Это, кажется, происходит из-за подкачки.