From: | Doug Knight <dknight(at)wsi(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_standby and build farm |
Date: | 2006-12-28 13:45:40 |
Message-ID: | 1167313540.3933.58.camel@arc-dknightlx.wsicorp.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thanks for the response, Simon. I'm continuing to use your script, so if
there's anything I can help you with (testing, ideas, etc), just let me
know.
Doug
On Thu, 2006-12-28 at 13:40 +0000, Simon Riggs wrote:
> On Wed, 2006-12-27 at 20:09 +0000, Simon Riggs wrote:
>
> > The reason for the -m option was performance. Recovery is I/O-bound,
> > with 50% of the CPU it does use coming from IsRecordValid() - which is
> > where the CRC checking takes place. (I can add an option to recover
> > without CRC checks, if anyone wants it, once I've rejigged the option
> > parsing for recovery.conf.)
>
> Make that 70% of the CPU, for long running recoveries, but the CPU only
> gets as high as 20% on my tests, so still I/O bound.
>
> > Should be able to use hard links, i.e. ln -f -s /archivepath/%f %p
> > instead. I'll test that tomorrow then issue a new version.
>
> The ln works, and helps, but not that much. I'll remove the -m option
> and replace it with an -l option. Must be careful to use the -f option.
>
> The majority of the I/O comes from writing dirty buffers, so enabling
> the bgwriter during recovery would probably be more helpful.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jie Zhang | 2006-12-28 14:37:34 | Re: Bitmap index thoughts |
Previous Message | Stefan Kaltenbrunner | 2006-12-28 13:41:57 | Re: Recent SIGSEGV failures in buildfarm HEAD |