PostgreSQL исключительно медленно разбирает чрезвычайно короткие запросы

Question

Я использую Zend Framework (PHP) и postgresql в качестве бэкэнда для хранения сессии. Иногда я получаю тонны журналов, как это:

Mar  8 11:07:00 myhost postgres[79149]: [30640132-1] 0 LOG:  00000: duration: 1401.742 ms  parse pdo_stmt_00000005: SELECT "sessions".* FROM "php"."sessions" WHERE ((("sessions"."id" = '3d5tmqutaeuivtf8a1udfa5i04')))
Mar  8 11:07:00 myhost postgres[79150]: [30640151-1] 0 LOG:  00000: duration: 1400.083 ms  parse pdo_stmt_00000007: SELECT "sessions".* FROM "php"."sessions" WHERE ((("sessions"."id" = 'b2vh1r29vnqg1e3600ther40c3')))
Mar  8 11:07:00 myhost postgres[79152]: [30640135-1] 0 LOG:  00000: duration: 1401.261 ms  parse pdo_stmt_00000005: SELECT "sessions".* FROM "php"."sessions" WHERE ((("sessions"."id" = '3d5tmqutaeuivtf8a1udfa5i04')))
Mar  8 11:07:00 myhost postgres[79147]: [30640166-1] 0 LOG:  00000: duration: 1381.648 ms  parse pdo_stmt_00000009: SELECT "sessions".* FROM "php"."sessions" WHERE ((("sessions"."id" = '6uj0955g64mmd9i8ra1q5nbtd5')))

Таблица php.sessions имеет в любой момент около 500-1000 строк.

Это кажется странным, поскольку выполнение этого оператора не было зарегистрировано как медленное, но синтаксический анализ почти "бесконечен".

Есть подсказка? Кто-нибудь знает какие-либо проблемы со скоростью парсера запросов postgres?

Некоторые технические знания:

Я использую PostgreSQL 8.4.9 на CentOS 6.0, это 2x 10-ядерная машина Intel с 128 ГБ ОЗУ. Процессор был использован только 20% - 25% в это самое время. Диск читает / пишет очень быстро. log_min_statement = 500

Answer 1

Этот случай выглядит так: много длинных бездействующих транзакций, т.е. в транзакции . Нам удалось избавиться от большинства из них. И результат выдающийся.

Главной причиной, к сожалению, стала ошибочная логика приложения. Я имею в виду, что часть транзакций выглядела так:

• 1010 * начинают *
• запрос
• запрос
• ожидание
• ... (много ожидания)
• ожидание
• * совершить 1028 *

Поскольку подсистеме управления версиями строк приходилось хранить много старых версий строк, система становилась все менее и менее отзывчивой (каждый простой запрос должен был искать подходящие версии строк).

Answer 2

У меня похожая ситуация на тестовом боксе в случаях, когда:

• Процессы с высокой загрузкой процессора выполняются на сервере;
• Системы начинают выгружать ОЗУ на диски для ОЗУ.интенсивные процессы.

PostgreSQL использует 2 уровня кэша данных:

1. общий пул, указанный через shared_buffers;
2. кэш ОС, указанный черезeffective_cache_size, не могли бы вы сказать нам, что вы цените здесь, пожалуйста?

Чтобы понять, что на самом деле происходит в вашей системе, вы должны следить за:

• CPUиспользование;
• использование ОЗУ;
• объемы ввода-вывода и подкачки.

По монитор Я имею в виду не просто просмотр текущих значений, новместо этого используются такие инструменты, как sar, iostat, vmstat и тому подобное, в сочетании, скажем, с RRDtool для лучшего анализа данных.А затем просмотрите подготовленные отчеты за период времени, в течение которого вы наблюдаете нежелательные задержки в простых запросах.

У меня такое ощущение, что у вас проблемы с вводом-выводом, но я не могу сказать больше, не глядя на систему и отчеты.

Я бы порекомендовал:

1. Настройка мониторинга и просмотра созданных отчетов;
2. Создать резервную базу данных в аналогичном окне, чтобы поиграть с различными настройками.(Я предполагаю, что у вас есть подходящие резервные копии базы данных и WAL для этого.) Я бы рассмотрел: память, автоочистку, контрольные точки и настройки WAL.
3. Подумайте об обновлении до PostgreSQL 9.1, за которым вы два основных релиза.