Re: Wait events monitoring future development
От | Tsunakawa, Takayuki |
---|---|
Тема | Re: Wait events monitoring future development |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1F5C012F@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Wait events monitoring future development (Ilya Kosmodemiansky <ilya.kosmodemiansky@postgresql-consulting.com>) |
Ответы |
Re: Wait events monitoring future development
|
Список | pgsql-hackers |
From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Ilya Kosmodemiansky
I've summarized Wait events monitoring discussion at Developer unconference in Ottawa this year on wiki:
https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Unconference/Wait_events_monitoring
I hope wait event monitoring will be on by default even if the overhead is not almost zero, because the data needs to be readily available for faster troubleshooting. IMO, the benefit would be worth even 10% overhead. If you disable it by default because of overhead, how can we convince users to enable it in production systems to solve some performance problem? I’m afraid severe users would say “we can’t change any setting that might cause more trouble, so investigate the cause with existing information.”
We should positively consider the performance with wait event monitoring on as the new normal. Then, we should develop more features that leverage the wait event data, so that wait event data is crucial. The manual explains to users that wait event monitoring can be turned off for maximal performance but it’s not recommended.
BTW, taking advantage of this chance, why don’t we enrich the content of performance tuning in the manual? At least it needs to be explained how to analyze the wait event data and tune the system.
Performance Tips
https://www.postgresql.org/docs/devel/static/performance-tips.html
Regards
Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: