From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Moreno Andreo <moreno(dot)andreo(at)evolu-s(dot)it>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: How to find the culprit in server load spikes? |
Date: | 2015-07-22 16:40:55 |
Message-ID: | 969868879.490578.1437583255126.JavaMail.yahoo@mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Moreno Andreo <moreno(dot)andreo(at)evolu-s(dot)it> wrote:
> I host a Postgresql server on Ubuntu 12.04 and I am facing server
> load spikes (if I run top, it goes up to 25-30 on a 4-core system)...
> In some cases, I have to restart potgresql service because users call us
> complaining of the slowness, but in some cases I can leave things on
> their way and I see that after a bunch of minutes (about 5-10) the
> situations drops to the normality (0.50-2 load).
>
> The problem is, as in the most cases, the I/O,
If you have confirmed that there is an I/O glut during these
episodes, it is probably that a cascade of dirty cache pages
caused the OS dirty pages to hit the vm.dirty_ratio percentage. If
you were seeing a high number for system CPU time the below would
probably not help.
Make sure you are using a storage system that has a persistent
cache configured for write-back (rather than write-through).
Reduce the OS vm.dirty_background_bytes setting to less than the
size of the persistent write cache. Make sure that vm.dirty_ratio
is at least 20, possibly higher. Configure the PostgreSQL
background writer to be more aggressive. If those don't do it,
reduce the size of shared_buffers.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2015-07-22 17:18:48 | Re: How to find the culprit in server load spikes? |
Previous Message | Moreno Andreo | 2015-07-22 12:50:48 | How to find the culprit in server load spikes? |