Message-Id: <4BA09919020000250002FE36@gw.wicourts.gov>
Date: Wed, 17 Mar 2010 08:55:53 -0500
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Renato Oliveira" <renato.oliveira@grant.co.uk>
Cc: <pgsql-admin@postgresql.org>
Subject: Re: PITR load on servers - increased 20%
References: <4B9A6E8B.4050303@magneta.com.cy>
	<1268556612.3825.5025.camel@ebony> <4B9DFD67.3050106@magneta.com.cy>
	<1268647021.3825.7469.camel@ebony>
	<7965A9DCF12CC14984420BCC37B1608F25AAFB989B@Elzar.grant.co.uk>
In-Reply-To: <7965A9DCF12CC14984420BCC37B1608F25AAFB989B@Elzar.grant.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Renato Oliveira <renato.oliveira@grant.co.uk> wrote:
 
> I have been testing PITR and I have noticed a 20% increase on the
> load of the Disk subsystem.
> 
> Is that a normal thing to expect?
 
It depends on your workload and archive script, but that doesn't
seem too shocking.
 
For one thing, turning on archiving causes more to be written to the
WAL files, so you should expect some increase just by enabling
archiving, even if your archive script just consists of 'exit 0'. 
Reading the WAL file in the archive script will often be reading
from OS cache, but not necessarily.  If you're copying the WAL files
to a local file system (which often makes sense), that obviously
increases I/O.  If there's enough delay between the archive script
writing the file to a local drive and something (e.g., rsync)
picking it up, it might need to read from the disk, and rsync is
likely to do some logging.
 
I would be surprised if you couldn't measure any increase, and 20%
is certainly within a reasonable range, depending on all the above. 
If you need to try to minimize the impact, besides considering all
of the above, you might want to look at the full_page_writes
configuration option.
 
http://www.postgresql.org/docs/8.4/interactive/runtime-config-wal.html#GUC-FULL-PAGE-WRITES
 
-Kevin