Re: performance statistics monitoring without spamming logs

Поиск
Список
Период
Сортировка
От Lukas Fittl
Тема Re: performance statistics monitoring without spamming logs
Дата
Msg-id CAP53PkzXLVzD2hwi4iVv-H7TuM-ZdUN52zE0tGcmtj5qf1o2Eg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: performance statistics monitoring without spamming logs  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: performance statistics monitoring without spamming logs
Список pgsql-performance
On Tue, Jul 10, 2018 at 11:38 AM, Justin Pryzby <pryzby@telsasoft.com> wrote:
> 2. Make stats available in `pg_stat_statements` (or alternate view that
> could be joined on). The block stats are already available here, but
> others like CPU usage, page faults, and context switches are not.

pg_stat_statements is ./contrib/pg_stat_statements/pg_stat_statements.c which is 3k LOC.

getrusage stuff and log_*_stat stuff is in src/backend/tcop/postgres.c

Before you start implementing something here, take a look at pg_stat_kcache [0]

Which already aims to collect a few more system statistics than what pg_stat_statements provides today, and might be a good basis to extend from.

It might also be worth to look at pg_stat_activity wait event sampling to determine where a system spends time, see e.g. pg_wait_sampling [1] for one approach to this.


Best,
Lukas 

--
Lukas Fittl

В списке pgsql-performance по дате отправления:

Предыдущее
От: Roman Konoval
Дата:
Сообщение: Re: High concurrency but simple updating causes deadlock
Следующее
От: Adrien NAYRAT
Дата:
Сообщение: Re: performance statistics monitoring without spamming logs