Re: High load average every 105 minutes

From: Nhan Nguyen <nhan(dot)nguyen(at)inspireventures(dot)com>
To: Chris Mair <chris(at)1006(dot)org>
Cc: John R Pierce <pierce(at)hogranch(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: High load average every 105 minutes
Date: 2016-11-08 02:41:00
Message-ID: 7CF067D4-1464-444A-8D04-2810FE70737D@inspireventures.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I forgot to mention, my DB is running on a c4.xlarge instance.

Nhan Nguyen
System Engineer

MB: (+84) 934 008 031
Skype: live:ducnhan813

> On Nov 7, 2016, at 5:03 PM, Chris Mair <chris(at)1006(dot)org> wrote:
>
>
>>> with AWS, your system is sharing the vendors virtual machine environment with other customers, and performance is pretty much out of your control.
>
>> I found no strange processes or queries while load average was at peak. IO also didn't change. Some more slow queries were logged, but not many.
>> I think sharing the VM with other customers doesn’t have much to do with this. I checked my other servers too, and only those that have postgresql have the load average issue. Generally it doesn’t impact my system much, but when there are slow queries, this issue just makes everything worse.
>
> Hi,
>
> generally speaking AWS is pretty good at isolating users (and you can request single tenancy machines or
> dedicated machines as well if you're concerned about this).
>
> However, if you're running t1 or t2 instances, you get the concept of CPU credits. When those run out, your
> system is slowed down until the credits recover. I could imagine that this way some cyclic load patterns
> emerge, if there is constant load on the machines.
>
> Nhan, what instance types are you running?
>
> Bye,
> Chris.
>
>
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message kaustubh kelkar 2016-11-08 03:27:23 Fwd: Creating multiple instances of postresql on Windows environment
Previous Message Michael Paquier 2016-11-08 02:17:31 Re: checkpoint_timout with no WAL activity