| From: | Thomas Kellerer <shammat(at)gmx(dot)net> |
|---|---|
| To: | pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle |
| Date: | 2021-10-08 16:07:17 |
| Message-ID: | ed3d7396-157e-7ed5-4344-0bdd5799ac6c@gmx.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mladen Gogala | 2021-10-08 16:38:19 | Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle |
| Previous Message | Julien Rouhaud | 2021-10-08 15:59:03 | Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle |