Профилирование PostgreSQL

Я изучаю приложение, поддерживаемое PostgreSQL.

Использование ЦП постоянно превышает 50% на современном Xeon с 4 ГБ ОЗУ. Из этих 50% использования ЦП 67% приходится на «пользователя» и 33% — на «систему» ​​(это машина с Linux). Система вообще не ожидает операций ввода-вывода.

Мне интересно, как я могу увидеть, как это процессорное время ломается.

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

Как вы думаете, можно ли значительно сократить это процессорное время пользователя, перейдя на подготовленные операторы? т. е. может ли время анализа SQL, время планирования запросов и т. д. занимать столько ЦП? Некоторые запросы довольно объемные (более 500-1000 символов).

Может ли кто-нибудь подтвердить, автоматически ли PostgreSQL нормализует специальные запросы и кэширует планы запросов для них, фактически делая их такими же эффективными, как подготовленный оператор (плюс время анализа SQL)?

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


postgresql
person Community    schedule 13.01.2009    source источник
comment
Какую версию PostgreSQL вы используете?   -  person Guy C    schedule 01.02.2009
comment
Это 8.1.4, хотя часть этого проекта состоит в том, чтобы довести его до 8.3.5.   -  person    schedule 04.02.2009
comment
Какова скорость наращивания/разрыва соединения? Мы видели много случаев, когда высокая загрузка ЦП базы данных была вызвана тем, что каждый запрос имел собственное кратковременное соединение в среде с очень высокой частотой одновременных запросов.   -  person Matthew Wood    schedule 02.12.2011

Ответы (2)


arrow_upward
7
arrow_downward

Предположим, вы регулярно ВАКУУМИРУЕМ базу данных (которая является стандартным источником проблем с производительностью PostgreSQL) Я думаю, что способ выиграть больше всего с точки зрения производительности —

a) настройте установку для производительности в зависимости от компьютера, на котором вы работаете, и

б) проанализировать каждый запрос и выяснить, может ли он быть оптимизировано дальше.

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

person Vinko Vrsalovic    schedule 13.01.2009
comment
Спасибо за ссылки. Знаете ли вы, кэширует ли PostgreSQL планы запросов для специальных SQL-запросов? - person ; 14.01.2009
comment
IIRC, это так. Хотя я не уверен на 100%. Отличным ресурсом для PostgreSQL являются его списки рассылки, где основные разработчики активны и отвечают на множество вопросов. - person Vinko Vrsalovic; 14.01.2009

arrow_upward
4
arrow_downward

Один трюк, который вы, возможно, еще не видели, заключается в использовании «top -c» для просмотра вашей системы. С помощью этого параметра вы можете увидеть, что на самом деле делает каждый активный процесс Postgres.

Планы запросов никаким образом не кэшируются в базе данных за пределами подготовленных операторов. В любом случае, если вы не используете повторно похожие запросы, маловероятно, что вы сможете сократить время запроса, используя подготовленные операторы. Вы можете даже усугубить ситуацию, если это приведет к тому, что оптимизатору будет предоставлено меньше информации для работы, потому что он готовит вещи до того, как узнает всю информацию о том, что он собирается делать. 1000 символов — это далеко не громоздкий запрос, и если у вас нет сотен подключений одновременно, маловероятно, что синтаксический анализ или планирование запросов — это ваша проблема. Это, вероятно, проблемы с блокировкой, плохие процедуры VACUUM, приводящие к раздутым данным, которые необходимо искать, чтобы выполнить какую-либо работу (очень легко встретить в 8.1), медленные ограничения, чрезмерные индексы или дизайн, который не учитывает накладные расходы на перемещение вещей. вокруг памяти полностью. Накладные расходы на запросы находятся очень низко в списке подозреваемых.

И если у вас есть сотни соединений, вам следует рассмотреть возможность использования пула соединений. Процесс создания PostgreSQL довольно трудоемкий, и сам по себе он не очень хорошо работает в этой среде.

Блин, у вас такая старая версия даже 8.1, что вы можете увидеть ошибку; 8.1.4 их полно. 8.1.19 актуальна, и даже 8.3.5 уже на несколько полезных обновлений версии отстает от текущей). См. Политику управления версиями, чтобы узнать, почему запуск более старой версии представляет больший риск, чем ситуация.

person Greg Smith    schedule 20.01.2010