Инструмент мониторинга производительности PostgreSQL

Question

Я настраиваю веб-приложение с бэкэндом FreeBSD PostgreSQL. Я ищу какой-нибудь инструмент / метод оптимизации производительности базы данных.

Answer 1

pgfouine работает довольно хорошо для меня. И, похоже, для этого есть порт FreeBSD .

Answer 2

Оптимизация базы данных обычно представляет собой сочетание двух вещей

<Ол>

Сократите количество запросов к базе данных

Сократите объем данных, которые необходимо просмотреть, чтобы ответить на запросы

Сокращение количества запросов обычно выполняется путем кэширования энергонезависимых / менее важных данных (например, «Какие пользователи в сети» или «Какие последние сообщения этого пользователя?») внутри приложения (если это возможно) ) или во внешнем - более эффективном - хранилище данных (memcached, redis и т. д.). Если у вас есть информация, которая требует большого объема записи (например, счетчики посещений) и не нуждается в ACID -семантику вы также можете подумать о перемещении ее из базы данных Postgres в более эффективные хранилища данных.

Оптимизация времени выполнения запроса более сложная - это может привести к созданию специальной indexes (или индексы в первую очередь ), меняя (возможно, денормализовать) модель данных или изменить фундаментальный подход, применяемый приложением, когда дело доходит до работы с базой данных. См., Например, разбиение на страницы, выполненное способом Postgres , выступая Маркус Винанд о том, как переосмыслить концепцию разбиения на страницы, чтобы сделать ее более эффективной для баз данных

Измерение запросов медленным способом

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

Одним из подходов к этому является регистрация всех (или «медленных») запросов, включая время их выполнения, и последующий анализ журнала запросов. Хороший инструмент для этого - pgfouine , который уже упоминался ранее в этом обсуждение, с тех пор его заменили pgbadger , который написан более дружественный язык, гораздо быстрее и активнее поддерживается.

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

Ускорение работы с расширениями

Для устранения этих недостатков теперь есть два расширения, которые отслеживают производительность запросов непосредственно в базе данных - pg_stat_statements (что полезно только в версии 9.2 или новее) и < код> pg_stat_plans . Оба расширения предлагают одинаковую базовую функциональность - отслеживание того, как часто данный «нормализованный запрос» (Строка запроса минус все литералы выражения) и сколько времени это заняло. В связи с тем, что это делается в то время, когда запрос фактически выполняется, это делается очень эффективным образом, в синтетических тестах измеримые издержки составили менее 5%.

Осмысление данных

Сам список запросов очень "сухой". с информационной точки зрения. Работает над третьим расширением, пытающимся устранить этот факт и предложить более качественное представление данных, называемых pg_statsinfo (вместе с pg_stats_reporter ), но это немного трудоемко

Answer 3

Я немного использовал pgtop. Это довольно грубо, но, по крайней мере, я вижу, какой запрос выполняется для каждого идентификатора процесса.

Я пробовал pgfouine, но если я помню, это автономный инструмент.

Я также добавляю файл psql.log и устанавливаю критерии ведения журнала до уровня, где я могу видеть проблемные запросы.

#log_min_duration_statement = -1        # -1 is disabled, 0 logs all statements
                                        # and their durations, > 0 logs only
                                        # statements running at least this time.

Я также использую EMS Postgres Manager для выполнения общих административных задач. Он ничего для вас не делает, но облегчает большинство задач и упрощает просмотр и настройку вашей схемы. Я обнаружил, что при использовании графического интерфейса мне намного легче обнаруживать несоответствия (например, отсутствующий индекс, критерии поля и т. Д.). Это только одна из двух программ, которые я хочу использовать на своем Mac с VMWare.

Answer 4

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

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

Ознакомьтесь с последними плагинами postgresql, которые поставляются с Munin здесь:

http://munin-monitoring.org/ браузер / филиалы / 1,4-стабильный / плагинов / node.d /

Answer 5

Ну, во-первых, попробуйте выполнить все ваши запросы из psql, используя " объяснение " и посмотрите, есть ли последовательные сканы, которые можно преобразовать в сканы индекса, добавив индексы или переписав запрос.

Кроме этого, я так же заинтересован в ответах на этот вопрос, как и вы.

Answer 6

Проверьте Lightning Admin, у него есть графический интерфейс для захвата операторов журнала, он не идеален, но отлично подходит для большинства задач. http://www.amsoftwaredesign.com

Answer 7

DBTuna http://www.dbtuna.com/postgresql_monitor.php недавно начал поддерживать Мониторинг PostgreSQL. Мы широко используем его для мониторинга MySQL, поэтому, если он обеспечивает то же самое для Postgres, то он также подойдет и вам.