pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedDetails after Load Peak was: OT: Performance of VM
4+ messages / 4 participants
[nested] [flat]
* Details after Load Peak was: OT: Performance of VM
@ 2018-02-06 14:31 Thomas Güttler <guettliml@thomas-guettler.de>
2018-02-06 15:30 ` Re: Details after Load Peak was: OT: Performance of VM Alan Hodgson <ahodgson@lists.simkin.ca>
2018-02-13 21:15 ` Re: Details after Load Peak was: OT: Performance of VM Gunnar "Nick" Bluth <gunnar.bluth@pro-open.de>
0 siblings, 2 replies; 4+ messages in thread
From: Thomas Güttler @ 2018-02-06 14:31 UTC (permalink / raw)
To: pgsql-performance@lists.postgresql.org
Am 05.02.2018 um 14:26 schrieb Andreas Kretschmer:
>
>
> Am 05.02.2018 um 14:14 schrieb Thomas Güttler:
>> What do you suggest to get some reliable figures?
>
> sar is often recommended, see https://blog.2ndquadrant.com/in-the-defense-of-sar/.
>
> Can you exclude other reasons like vacuum / vacuum freeze?
In the current case it was a problem in the hypervisor.
But I want to be prepared for the next time.
The tool sar looks good. This way I can generate a chart where I can see peaks. Nice.
.... But one thing is still unclear. Imagine I see a peak in the chart. The peak
was some hours ago. AFAIK sar has only the aggregated numbers.
But I need to know details if I want to answer the question "Why?". The peak
has gone and ps/top/iotop don't help me anymore.
Any idea?
Regards,
Thomas Güttler
--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Details after Load Peak was: OT: Performance of VM
2018-02-06 14:31 Details after Load Peak was: OT: Performance of VM Thomas Güttler <guettliml@thomas-guettler.de>
@ 2018-02-06 15:30 ` Alan Hodgson <ahodgson@lists.simkin.ca>
1 sibling, 0 replies; 4+ messages in thread
From: Alan Hodgson @ 2018-02-06 15:30 UTC (permalink / raw)
To: pgsql-performance@lists.postgresql.org
On Tue, 2018-02-06 at 15:31 +0100, Thomas Güttler wrote:
>
.... But one thing is still unclear. Imagine I see a peak in the chart. The peak
> was some hours ago. AFAIK sar has only the aggregated numbers.
>
> But I need to know details if I want to answer the question "Why?". The peak
> has gone and ps/top/iotop don't help me anymore.
>
The typical solution is to store stats on everything you can think of
with munin, cacti, ganglia, or similar systems.
I know with ganglia at least, in addition to all the many details it
already tracks on a system and the many plugins already available for
it, you can write your own plugins or simple agents, so you can keep
stats on anything you can code around.
Munin's probably the easiest to try out, though.
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Details after Load Peak was: OT: Performance of VM
2018-02-06 14:31 Details after Load Peak was: OT: Performance of VM Thomas Güttler <guettliml@thomas-guettler.de>
@ 2018-02-13 21:15 ` Gunnar "Nick" Bluth <gunnar.bluth@pro-open.de>
2018-02-13 21:55 ` Re: Details after Load Peak was: OT: Performance of VM Micky Gough <mgough@squiz.net>
1 sibling, 1 reply; 4+ messages in thread
From: Gunnar \"Nick\" Bluth @ 2018-02-13 21:15 UTC (permalink / raw)
To: pgsql-performance@lists.postgresql.org
Am 06.02.2018 um 15:31 schrieb Thomas Güttler:
>
>
> Am 05.02.2018 um 14:26 schrieb Andreas Kretschmer:
>>
>>
>> Am 05.02.2018 um 14:14 schrieb Thomas Güttler:
>>> What do you suggest to get some reliable figures?
>>
>> sar is often recommended, see
>> https://blog.2ndquadrant.com/in-the-defense-of-sar/.
>>
>> Can you exclude other reasons like vacuum / vacuum freeze?
>
> In the current case it was a problem in the hypervisor.
>
> But I want to be prepared for the next time.
>
> The tool sar looks good. This way I can generate a chart where I can see
> peaks. Nice.
>
> .... But one thing is still unclear. Imagine I see a peak in the chart.
> The peak
> was some hours ago. AFAIK sar has only the aggregated numbers.
>
> But I need to know details if I want to answer the question "Why?". The
> peak
> has gone and ps/top/iotop don't help me anymore.
>
> Any idea?
I love atop (atoptool.nl) for exactly that kind of situation. It will
save a snapshot every 10 minutes by default, which you can then simply
"scroll" back to. Helped me pinpointing nightly issues countless times.
Only really available for Linux though (in case you're on *BSD).
Best regards,
--
Gunnar "Nick" Bluth
RHCE/SCLA
Mobil +49 172 8853339
Email: gunnar.bluth@pro-open.de
_____________________________________________________________
In 1984 mainstream users were choosing VMS over UNIX.
Ten years later they are choosing Windows over UNIX.
What part of that message aren't you getting? - Tom Payne
Attachments:
[application/pgp-signature] signature.asc (472B, ../../5faea40d-66db-9c23-0256-4e37de1e0d6b@pro-open.de/2-signature.asc)
download
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Details after Load Peak was: OT: Performance of VM
2018-02-06 14:31 Details after Load Peak was: OT: Performance of VM Thomas Güttler <guettliml@thomas-guettler.de>
2018-02-13 21:15 ` Re: Details after Load Peak was: OT: Performance of VM Gunnar "Nick" Bluth <gunnar.bluth@pro-open.de>
@ 2018-02-13 21:55 ` Micky Gough <mgough@squiz.net>
0 siblings, 0 replies; 4+ messages in thread
From: Micky Gough @ 2018-02-13 21:55 UTC (permalink / raw)
To: Gunnar Nick Bluth <gunnar.bluth@pro-open.de>; +Cc: pgsql-performance@lists.postgresql.org
+1 for atop. Be sure to adjust the sampling interval so it suits your
needs. It'll tell you what caused the spike.
Alternatively you could probably use sysdig, but I expect that'd result in
a fair performance hit if your system is already struggling.
Micky
On 14 February 2018 at 08:15, Gunnar "Nick" Bluth <gunnar.bluth@pro-open.de>
wrote:
> Am 06.02.2018 um 15:31 schrieb Thomas Güttler:
> >
> >
> > Am 05.02.2018 um 14:26 schrieb Andreas Kretschmer:
> >>
> >>
> >> Am 05.02.2018 um 14:14 schrieb Thomas Güttler:
> >>> What do you suggest to get some reliable figures?
> >>
> >> sar is often recommended, see
> >> https://blog.2ndquadrant.com/in-the-defense-of-sar/.
> >>
> >> Can you exclude other reasons like vacuum / vacuum freeze?
> >
> > In the current case it was a problem in the hypervisor.
> >
> > But I want to be prepared for the next time.
> >
> > The tool sar looks good. This way I can generate a chart where I can see
> > peaks. Nice.
> >
> > .... But one thing is still unclear. Imagine I see a peak in the chart.
> > The peak
> > was some hours ago. AFAIK sar has only the aggregated numbers.
> >
> > But I need to know details if I want to answer the question "Why?". The
> > peak
> > has gone and ps/top/iotop don't help me anymore.
> >
> > Any idea?
>
> I love atop (atoptool.nl) for exactly that kind of situation. It will
> save a snapshot every 10 minutes by default, which you can then simply
> "scroll" back to. Helped me pinpointing nightly issues countless times.
>
> Only really available for Linux though (in case you're on *BSD).
>
> Best regards,
> --
> Gunnar "Nick" Bluth
> RHCE/SCLA
>
> Mobil +49 172 8853339
> Email: gunnar.bluth@pro-open.de
> _____________________________________________________________
> In 1984 mainstream users were choosing VMS over UNIX.
> Ten years later they are choosing Windows over UNIX.
> What part of that message aren't you getting? - Tom Payne
>
>
>
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2018-02-13 21:55 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-02-06 14:31 Details after Load Peak was: OT: Performance of VM Thomas Güttler <guettliml@thomas-guettler.de>
2018-02-06 15:30 ` Alan Hodgson <ahodgson@lists.simkin.ca>
2018-02-13 21:15 ` Gunnar "Nick" Bluth <gunnar.bluth@pro-open.de>
2018-02-13 21:55 ` Micky Gough <mgough@squiz.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox