Как вы измеряете профиль нагрузки (соотношение кол-ва чтений/кол-ву записей) в PostgreSQL?

Question

[Антон Пацев]

Добрый день!
Как вы измеряете профиль нагрузки (соотношение кол-ва чтений/кол-ву записей) в PostgreSQL?
Можно конечно мониторить только дисковое чтение и запись, но тогда не будет учитываться кеш.
Вы мониторите дисковое чтение и запись и отдельно кол-во запросов в PostgreSQL?
Заранее спасибо
P.S. Про pg_stat_statements я знаю. Но pg_stat_statements не дает кол-во чтений на сервере PostgreSQL, там есть кол-во запросов, но не чтений.

P.S.1 Есть ли какой-нибудь SQL запрос, который показывал суммарное кол-во SELECT на сервер?
Есть ли какой-нибудь SQL запрос, который показывал суммарное кол-во (UPDATE + DELETE) на сервер?

P.S.2
Эта нужная метрика - допустим сейчас все запросы идут на мастер в кластере, можно показать что у нас профиль нагрузки 70% чтение / 30% запись или 80% чтение / 20% запись.
И с помощью перевода SELECT запросов на SLAVE - можно снизить нагрузку на кластер PostgreSQL

Answer 1

[Melkij]

Посмотрите в циферки что собирает stats collector, их много разных. https://www.postgresql.org/docs/10/static/monitori...
например, запись буферов на диски - это buffers_checkpoint, buffers_clean и buffers_backend в pg_stat_bgwriter
pg_stat_database c blks_read, blks_hit, blk_read_time и blk_write_time

И разумеется pg_stat_statements с детализацией ресурсов по отдельным запросам.

Вот кстати, хорошая картинка куда смотреть за детализацией каких подсистем базы

Comments

[Антон Пацев]

Обновил текста вопроса

[Melkij]

Бессмысленная метрика. Нет, отдельных счётчиков нет.
Осмысленная метрика - сколько таплов читали-писали: n_tup_ins/n_tup_upd/n_tup_del/n_tup_hot_upd/seq_tup_read/idx_tup_fetch в pg_stat_all_tables.
И другая осмысленная метрика - topN запросов по времени выполнения из pg_stat_statements.

[Антон Пацев]

Melkij, Почему бесмысленная метрика - допустим сейчас все запросы идут на мастер в кластере, можно показать что у нас профиль нагрузки 70% чтение / 30% запись или 80% чтение / 20% запись.
И с помощью перевода SELECT запросов на SLAVE - можно снизить нагрузку на кластер PostgreSQL

[Melkij]

Потому что соотношение чтения к записи не делают по числу запросов. Знаете ли, select одной строки по первичному ключу и половины таблицы seqscan'ом - это всё ещё один запрос с кардинально разными затратами io.

А с переносом части чтения на реплики - берёте topN отчёт и так и говорите:

ребята, смотрите: у нас дофига нагрузки вот от этих пары oltp запросов. Они же вроде не критичны к мелкому лагу? Давайте их на реплику скинем.
А вот этот милый запрос на 20% суточной нагрузки - это же вообще аналитика за прошлые сутки для менеджеров, давайте на аналитическую slow реплику перенесём, нафиг оно нам на мастере автовакууму мешает

Answer 2

[ky0]

Поддерживаю насчёт pg_stat_statements, есть масса способов извлечь оттуда полезную информацию, см. например https://github.com/dataegret/pg-utils

Comments

[Антон Пацев]

Обновил текста вопроса