Thread: PITR performance costs
Since PITR has to enable archiving does this not increase the amount of disk I/O required ? Dave
Dave Cramer <pg@fastcrypt.com> wrote: > Since PITR has to enable archiving does this not increase the amount > of disk I/O required ? It does increase the required amount of I/O. -- Bill Moran http://www.potentialtech.com
am Mon, dem 28.05.2007, um 8:45:38 -0400 mailte Dave Cramer folgendes: > Since PITR has to enable archiving does this not increase the amount > of disk I/O required ? Yes. But you can use a different hard drive for this log. Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net
Dave Cramer wrote: > Since PITR has to enable archiving does this not increase the amount of > disk I/O required ? There's no difference in normal DML operations, but some bulk operations like CREATE INDEX that don't otherwise generate WAL, need to be WAL logged when archiving is enabled. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki, Don't the archived logs have to be copied as well as the regular WAL logs get recycled ? Dave On 28-May-07, at 12:31 PM, Heikki Linnakangas wrote: > Dave Cramer wrote: >> Since PITR has to enable archiving does this not increase the >> amount of disk I/O required ? > > There's no difference in normal DML operations, but some bulk > operations like CREATE INDEX that don't otherwise generate WAL, > need to be WAL logged when archiving is enabled. > > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com
Dave, et al,
* Dave Cramer (pg@fastcrypt.com) wrote:
> Don't the archived logs have to be copied as well as the regular WAL
> logs get recycled ?
Yes, but I'd expect at the point they're being copied off to some other
store (probably a seperate disk, or even over the network to another
system, etc), they're probably in the system cache, so you're probably
not going out to disk to get those blocks anyway. That might not be the
case on a slow-write system, but in those cases it seems at least
somewhat unlikely you'll be hit very hard by the occational 16MB copy
off the disk...
Thanks,
Stephen
> On 28-May-07, at 12:31 PM, Heikki Linnakangas wrote:
>
> >Dave Cramer wrote:
> >>Since PITR has to enable archiving does this not increase the
> >>amount of disk I/O required ?
> >
> >There's no difference in normal DML operations, but some bulk
> >operations like CREATE INDEX that don't otherwise generate WAL,
> >need to be WAL logged when archiving is enabled.
> >
> >--
> > Heikki Linnakangas
> > EnterpriseDB http://www.enterprisedb.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
Attachment
On Mon, 2007-05-28 at 08:45 -0400, Dave Cramer wrote: > Since PITR has to enable archiving does this not increase the amount > of disk I/O required ? As Heikki says, some operations need logging when PITR is on; these are now documented in the performance tips section of the latest dev docs: http://developer.postgresql.org/pgdocs/postgres/populate.html#POPULATE-PITR This isn't additional logging because of PITR, its just that we've had to exclude PITR from some recent tuning operations. I'll be looking at ways of making that optional in certain cases. Overall, the cost of shipping WAL files away has been measured in large scale tests by Mark Wong to be around 1% drop in measured peak transaction throughput, tests about ~2 years ago now on 8.0. It's possible that has increased as we have further tuned the server, but I'm thinking its still fairly negligible overall. Replication solutions currently weigh in significantly more than this overhead, which is one reason to make me start thinking about log based replication in future releases. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
On 5/28/07, Dave Cramer <pg@fastcrypt.com> wrote: > Since PITR has to enable archiving does this not increase the amount > of disk I/O required ? I've set up warm standbys on a few servers (some of them quite busy!)...the additional load is virtually unmeasurable. I usually don't copy the files locally...I scp them off to some other server. When archived, the WAL files are likely cached but there is some overhead to copying them off however. merlin