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

Question

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

Answer 1

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

1. Уменьшить количество запросов к базе данных
2. Сокращение количества данных, которые необходимо просмотреть, чтобы ответить на запросы

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

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

Медленное измерение запросов

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

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

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

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

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

Смысл данных

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

Чтобы предложить более удобное решение этой проблемы, я начал работать над коммерческим проектом, который сфокусирован на pg_stat_statements и pg_stat_plans и дополняет информацию, собранную множеством других данных, извлеченных из базы данных. Он называется pganalyze, и вы можете найти его в https://pganalyze.com/.

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

Answer 2

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

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

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

Answer 6

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

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

Answer 7

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