pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedPITR performance overhead?
4+ messages / 4 participants
[nested] [flat]
* PITR performance overhead?
@ 2006-08-01 16:15 George Pavlov <gpavlov@mynewplace.com>
0 siblings, 2 replies; 4+ messages in thread
From: George Pavlov @ 2006-08-01 16:15 UTC (permalink / raw)
To: pgsql-performance
I am looking for some general guidelines on what is the performance
overhead of enabling point-in-time recovery (archive_command config) on
an 8.1 database. Obviously it will depend on a multitude of factors, but
some broad-brush statements and/or anecdotal evidence will suffice.
Should one worry about its performance implications? Also, what can one
do to mitigate it?
Thanks,
George
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: PITR performance overhead?
@ 2006-08-01 16:59 Bill Moran <wmoran@collaborativefusion.com>
parent: George Pavlov <gpavlov@mynewplace.com>
1 sibling, 0 replies; 4+ messages in thread
From: Bill Moran @ 2006-08-01 16:59 UTC (permalink / raw)
To: George Pavlov <gpavlov@mynewplace.com>; +Cc: pgsql-performance
In response to "George Pavlov" <gpavlov@mynewplace.com>:
> I am looking for some general guidelines on what is the performance
> overhead of enabling point-in-time recovery (archive_command config) on
> an 8.1 database. Obviously it will depend on a multitude of factors, but
> some broad-brush statements and/or anecdotal evidence will suffice.
> Should one worry about its performance implications? Also, what can one
> do to mitigate it?
Prior to implementing PITR, I did some testing to see what kind of
overhead it would add. It was negligible. I don't remember the details,
but I seem to remember the performance hit was barely measurable.
Note that in our usage scenarios, we have very little IO compared to
CPU usage. The result is that our DB servers have plenty of disk
bandwidth to spare. Since the log backup occurs as a background
process, it made almost no difference in our tests. If your DB is
very IO intensive, you may have different results.
--
Bill Moran
Collaborative Fusion Inc.
****************************************************************
IMPORTANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
****************************************************************
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: PITR performance overhead?
@ 2006-08-02 01:17 Merlin Moncure <mmoncure@gmail.com>
parent: George Pavlov <gpavlov@mynewplace.com>
1 sibling, 1 reply; 4+ messages in thread
From: Merlin Moncure @ 2006-08-02 01:17 UTC (permalink / raw)
To: George Pavlov <gpavlov@mynewplace.com>; +Cc: pgsql-performance
On 8/1/06, George Pavlov <gpavlov@mynewplace.com> wrote:
> I am looking for some general guidelines on what is the performance
> overhead of enabling point-in-time recovery (archive_command config) on
> an 8.1 database. Obviously it will depend on a multitude of factors, but
> some broad-brush statements and/or anecdotal evidence will suffice.
> Should one worry about its performance implications? Also, what can one
> do to mitigate it?
pitr is extremely cheap both in performance drag and administation
overhead for the benefits it provides. it comes almost for free, just
make sure you can handle all the wal files and do sane backup
scheduling. in fact, pitr can actually reduce the load on a server
due to running less frequent backups. if your server is heavy i/o
loaded, it might take a bit of planning.
merlin
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: PITR performance overhead?
@ 2006-08-03 05:21 Denis Lussier <denisl@enterprisedb.com>
parent: Merlin Moncure <mmoncure@gmail.com>
0 siblings, 0 replies; 4+ messages in thread
From: Denis Lussier @ 2006-08-03 05:21 UTC (permalink / raw)
To: Merlin Moncure <mmoncure@gmail.com>; +Cc: George Pavlov <gpavlov@mynewplace.com>; pgsql-performance
If your server is heavily I/O bound AND you care about your data AND your
are throwing out your WAL files in the middle of the day... You are headed
for a cliff.
I'm sure this doesn't apply to anyone on this thread, just a general
reminder to all you DBA's out there who sometimes are too busy to implement
PITR until after a disaster strikes. I know that in the past I've
personally been guilty of this on several occasions.
--Denis
EnterpriseDB (yeah, rah, rah...)
On 8/1/06, Merlin Moncure <mmoncure@gmail.com> wrote:
>
> On 8/1/06, George Pavlov <gpavlov@mynewplace.com> wrote:
> > I am looking for some general guidelines on what is the performance
> > overhead of enabling point-in-time recovery (archive_command config) on
> > an 8.1 database. Obviously it will depend on a multitude of factors, but
> > some broad-brush statements and/or anecdotal evidence will suffice.
> > Should one worry about its performance implications? Also, what can one
> > do to mitigate it?
>
> pitr is extremely cheap both in performance drag and administation
> overhead for the benefits it provides. it comes almost for free, just
> make sure you can handle all the wal files and do sane backup
> scheduling. in fact, pitr can actually reduce the load on a server
> due to running less frequent backups. if your server is heavy i/o
> loaded, it might take a bit of planning.
>
> merlin
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2006-08-03 05:21 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-08-01 16:15 PITR performance overhead? George Pavlov <gpavlov@mynewplace.com>
2006-08-01 16:59 ` Bill Moran <wmoran@collaborativefusion.com>
2006-08-02 01:17 ` Merlin Moncure <mmoncure@gmail.com>
2006-08-03 05:21 ` Denis Lussier <denisl@enterprisedb.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox