> >>> Decibel! <decibel@decibel.org> 08/07/07 4:51 PM >>>
> On Tue, Aug 07, 2007 at 02:12:29PM -0500, Kevin Grittner wrote:
> > > Copying a 16MB file that's already in memory isn't exactly an intensive
> > > operation...
> >
> > That's true for the WAL files. The base backups are another story. We will
> > normally have a database vacuum analyze between the base backup and the users
> > being in there to care about performance, but that's not always the case --
> > sometimes jury trials go late into the night and could overlap with this a
> > base backup. And some judges put in a lot of late hours; although they don't
> > tend to bang on the database very heavily, they hate to be made to wait.
>
> Ahh... well, that's something where rsync could actually help you since
> it allows you to put a bandwidth cap on it. Another option is that some
> OSes (FreeBSD for one) will respect process priority when it comes to
> scheduling IO as well, so if you nice the backup process it hopefully
> wouldn't impact the database as much.
Thanks for the suggestions. A new OS is not in the cards any time soon, but
I think the --bwlimit option makes sense -- there's not a lot of point moving
it from the database server to the file server faster than the WAN can take it,
anyway. I suppose I could "nice" the rsync requester on the database side, too.
-Kevin
