Hi guys,
I just wanted to tell you, that now the originating problem, namely that backups (with pg_dump) were much slower on the
newhardware IS solved. After setting " zone_reclaim_mode = 0", my backups last night were fast as expected ... for my
100GByte DB it took now only 1 hour (instead of 6 1/2 with "zone_reclaim_mode = 1" ).
And again, thank you all for the good tips (especially about the tools to analyze the issue - I have learned a lot in
theprocess) which helped me to pin the problem down!
I will consider to post it to LKML 8as time permits) or to Ubuntu ...
By the way, would it maybe make sense, to put this information in the PostgreSQL Documentation ... as a kind of
cautionarywarning? Could make life for some admins easier in the future (especially if Ubuntu or other distributions
bringdifferent settings here).
Andras Fabian
-----Ursprüngliche Nachricht-----
Von: Scott Marlowe [mailto:scott.marlowe@gmail.com]
Gesendet: Mittwoch, 14. Juli 2010 05:33
An: Craig Ringer
Cc: Andras Fabian; pgsql-general@postgresql.org
Betreff: Re: [GENERAL] PG_DUMP very slow because of STDOUT ??
On Tue, Jul 13, 2010 at 9:10 PM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
>> And tomorrow I will see how my nightly backup runs with this setting.
>
> It sounds like it's time for a post to the Linux Kernel Mailing List,
> and/or a Launchpad bug against the Ubuntu kernel.
>
> Make sure to have your asbestos undewear on if posting to LKML ;-)
Note that I am testing a new 48 core machine with gobs of ram under
ubuntu 10.04, so I'll do some testing to see if I get the same kind of
issue, especially once I subscribe one of these machines to the slony
farm and get some action going on it to fill its buffers.
Note that the page posted earlier that described zone_reclaim_mode
said that when the memory is mostly used for file caching it's a good
idea to set it to 0. Even though they said that they were talking
about file servers, I'd assume that applies to pgsql as well, since
it's normal to use most of the extra memory as file system cache.