DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.it;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=QVkVyCtR6VprzUNQrglLx11Z2SFpLoFBqUXzvfXa8dyilsH68uux4aVyzNilSkZxxj8MSPfQzgLkkf69D8/vKbNK4NgLjJ1PXGnPt7VxmDTLHkksYkv1NVj/qbakHM+TWGs9KPNCweOYZ9/57jfzGa4uuh/BvSbOkEhROcHH95Q=;
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>
Message-ID: <1318323477.19815.YahooMailNeo@web29005.mail.ird.yahoo.com>
Date: Tue, 11 Oct 2011 09:57:57 +0100 (BST)
From: Leonardo Francalanci <m_lists@yahoo.it>
Reply-To: Leonardo Francalanci <m_lists@yahoo.it>
Subject: Re: Adding more memory = hugh cpu load
To: Greg Smith <greg@2ndQuadrant.com>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
In-Reply-To: <4E93E746.10807@2ndQuadrant.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

> checkpoint_completion_targets spreads out the writes to disk.=A0 PostgreS=
QL=A0=0A=0A> doesn't make any attempt yet to spread out the sync calls.=A0 =
On a busy =0A> server, what can happen is that the whole OS write cache fil=
ls with dirty =0A> data--none of which is written out to disk because of th=
e high kernel =0A> threshold--and then it all slams onto disk fast once the=
 checkpoint starts =0A> executing sync calls.=A0 Lowering the size of the L=
inux write cache helps with =0A> that a lot, but can't quite eliminate the =
problem.=0A=0A=0AOk, I understand now=0A=0A> Except that PostgreSQL doesn't=
 look after the fsync calls yet.=A0 I wrote a=A0=0A=0A> patch for 9.1 that =
spread out the sync calls, similarly to how the writes are =0A> spread out =
now.=A0 I wasn't able to prove an improvement sufficient to commit =0A> the=
 result.=A0 In the Linux case, the OS has more information to work with abo=
ut =0A> how to schedule I/O efficiently given how the hardware is acting, a=
nd it's =0A> not possible for PostgreSQL to know all that--not without dupl=
icating a large =0A> portion of the kernel development work at least.=A0 Ri=
ght now, relying the kernel =0A> means that any improvements there magicall=
y apply to any PostgreSQL version.=A0 So =0A> far the results there have be=
en beating out improvements made to the database =0A> fast enough that it's=
 hard to innovate in this area within Postgres.=0A=0A=0AOk; thank you very =
much for the explanation.=0A=0AIn fact, shouldn't those things be explained=
 in the "WAL Configuration" section=0Aof the manual? It looks as important =
as configuring Postgresql itself...=0AAnd: that applies to Linux. What abou=
t other OS, such as Solaris and FreeBSD?