Re: PITR load on servers - increased 20%

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Renato Oliveira" <renato(dot)oliveira(at)grant(dot)co(dot)uk>
Cc: <pgsql-admin(at)postgresql(dot)org>
Subject: Re: PITR load on servers - increased 20%
Date: 2010-03-17 13:55:53
Message-ID: 4BA09919020000250002FE36@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Renato Oliveira <renato(dot)oliveira(at)grant(dot)co(dot)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

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Vitaly Burshteyn 2010-03-17 14:41:06 pg_stop_backup()
Previous Message Rangi, Jai 2010-03-16 23:45:02 Re: Pgsql Training.