Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
От | Thomas Kellerer |
---|---|
Тема | Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle |
Дата | |
Msg-id | ed3d7396-157e-7ed5-4344-0bdd5799ac6c@gmx.net обсуждение исходный текст |
Ответ на | Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-performance |
Bruce Momjian schrieb am 08.10.2021 um 17:40: >> I guess everyone will use that information in a different way. >> >> We typically use the AWR reports as a post-mortem analysis tool if >> something goes wrong in our application (=customer specific projects) >> >> E.g. if there was a slowdown "last monday" or "saving something took minutes yesterday morning", >> then we usually request an AWR report from the time span in question. Quite frequently >> this already reveals the culprit. If not, we ask them to poke in more detail into v$session_history. >> >> So in our case it's not really used for active monitoring, but for >> finding the root cause after the fact. >> >> I don't know how representative this usage is though. > > OK, that's a good usecase, and something that certainly would apply to > Postgres. Don't you often need more than just wait events to find the > cause, like system memory usage, total I/O, etc? Yes, the AWR report contains that information as well. e.g. sorts that spilled to disk, shared memory at the start and end, top 10 statements sorted by total time, individual time, I/O, number of executions, segments (tables) that received the highest I/O (read and write) and so on. It's really huge.
В списке pgsql-performance по дате отправления: