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

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

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

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

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

измерение запросов медленный путь

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

один из подходов к этому-ведение журнала всех (или" медленных") запросов, включая их время выполнения, а затем анализ журнала запросов. Хорошим инструментом для этого является 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, который регулярно обновляется.

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

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

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

#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 для выполнения общей работы администратора. Это ничего не делает для вас, но это делает большинство задач проще и делает обзор и Настройка схемы более проста. Я нахожу, что при использовании GUI мне намного легче обнаружить несоответствия (например, отсутствующий индекс, критерии поля и т. д.). Это только одна из двух программ, которые я готов использовать VMWare на своем Mac.

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

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

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

http://munin-monitoring.org/browser/branches/1.4-stable/plugins/node.d/

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

кроме этого, я так же интересуют ответы на этот вопрос, как и вы.

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

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