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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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