Re: pg_standby and build farm
От | Doug Knight |
---|---|
Тема | Re: pg_standby and build farm |
Дата | |
Msg-id | 1167313540.3933.58.camel@arc-dknightlx.wsicorp.com обсуждение исходный текст |
Ответ на | Re: pg_standby and build farm ("Simon Riggs" <simon@2ndquadrant.com>) |
Ответы |
Re: pg_standby and build farm
|
Список | 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.<br /><br /> Doug<br /><br /> On Thu, 2006-12-28 at 13:40 +0000, Simon Riggs wrote:<blockquote type="CITE"><pre> <font color="#000000">On Wed, 2006-12-27 at 20:09 +0000, Simon Riggs wrote:</font> <font color="#000000">> The reason for the -m option was performance. Recovery is I/O-bound,</font> <font color="#000000">> with 50% of the CPU it does use coming from IsRecordValid() - which is</font> <font color="#000000">> where the CRC checking takes place. (I can add an option to recover</font> <font color="#000000">> without CRC checks, if anyone wants it, once I've rejigged the option</font> <font color="#000000">> parsing for recovery.conf.)</font> <font color="#000000">Make that 70% of the CPU, for long running recoveries, but the CPU only</font> <font color="#000000">gets as high as 20% on my tests, so still I/O bound.</font> <font color="#000000">> Should be able to use hard links, i.e. ln -f -s /archivepath/%f %p</font> <font color="#000000">> instead. I'll test that tomorrow then issue a new version.</font> <font color="#000000">The ln works, and helps, but not that much. I'll remove the -m option</font> <font color="#000000">and replace it with an -l option. Must be careful to use the -f option.</font> <font color="#000000">The majority of the I/O comes from writing dirty buffers, so enabling</font> <font color="#000000">the bgwriter during recovery would probably be more helpful.</font> </pre></blockquote>
В списке pgsql-hackers по дате отправления: