From: Leonardo Francalanci <m_lists@yahoo.it>
To: Greg Smith <greg@2ndQuadrant.com>
To: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Adding more memory = hugh cpu load
Date: Tue, 11 Oct 2011 09:57:57 +0100 (BST)
Message-ID: <1318323477.19815.YahooMailNeo@web29005.mail.ird.yahoo.com> (raw)
In-Reply-To: <4E93E746.10807@2ndQuadrant.com>
References: <4E92F294.9010405@gmail.com>
<4E92FB87.1030703@peak6.com>
<1318259675.10344.YahooMailNeo@web29011.mail.ird.yahoo.com>
<4E93119C.8090407@peak6.com>
<1318263277.56967.YahooMailNeo@web29013.mail.ird.yahoo.com>
<4E93E746.10807@2ndQuadrant.com>
> checkpoint_completion_targets spreads out the writes to disk. PostgreSQL
> doesn't make any attempt yet to spread out the sync calls. On a busy
> server, what can happen is that the whole OS write cache fills with dirty
> data--none of which is written out to disk because of the high kernel
> threshold--and then it all slams onto disk fast once the checkpoint starts
> executing sync calls. Lowering the size of the Linux write cache helps with
> that a lot, but can't quite eliminate the problem.
Ok, I understand now
> Except that PostgreSQL doesn't look after the fsync calls yet. I wrote a
> patch for 9.1 that spread out the sync calls, similarly to how the writes are
> spread out now. I wasn't able to prove an improvement sufficient to commit
> the result. In the Linux case, the OS has more information to work with about
> how to schedule I/O efficiently given how the hardware is acting, and it's
> not possible for PostgreSQL to know all that--not without duplicating a large
> portion of the kernel development work at least. Right now, relying the kernel
> means that any improvements there magically apply to any PostgreSQL version. So
> far the results there have been beating out improvements made to the database
> fast enough that it's hard to innovate in this area within Postgres.
Ok; thank you very much for the explanation.
In fact, shouldn't those things be explained in the "WAL Configuration" section
of the manual? It looks as important as configuring Postgresql itself...
And: that applies to Linux. What about other OS, such as Solaris and FreeBSD?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: m_lists@yahoo.it, greg@2ndQuadrant.com
Subject: Re: Adding more memory = hugh cpu load
In-Reply-To: <1318323477.19815.YahooMailNeo@web29005.mail.ird.yahoo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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