From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Thomas Kellerer <shammat(at)gmx(dot)net>, Pgsql Performance <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 15:59:03 |
Message-ID: | CAOBaU_b-LzjFZmmEnapBa=7SAfie=8NQVK5f0Vhic1DCB7gmTQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, Oct 8, 2021 at 11:40 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> On Fri, Oct 8, 2021 at 05:28:37PM +0200, Thomas Kellerer wrote:
> >
> > 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?
You usually need a variety of metrics to be able to find what is
actually causing $random_incident, so the more you can aggregate in
your performance tool the better. Wait events are an important piece
of that puzzle.
As a quick example for wait events, I recently had to diagnose some
performance issue, which turned out to be some process reaching the 64
subtransactions with the well known consequences. I had
pg_wait_sampling aggregated metrics available so it was really easy to
know that the slowdown was due to that. Knowing what application
exactly reached those 64 subtransactions is another story.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2021-10-08 16:07:17 | Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle |
Previous Message | Bruce Momjian | 2021-10-08 15:40:23 | Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle |