Hi guys, I just wanted to tell you, that now the originating problem, namely that backups (with pg_dump) were much slower on the new hardware IS solved. After setting " zone_reclaim_mode = 0", my backups last night were fast as expected ... for my 100 GByte 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 the process) 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 cautionary warning? Could make life for some admins easier in the future (especially if Ubuntu or other distributions bring different settings here). Andras Fabian -----Ursprüngliche Nachricht----- Von: Scott Marlowe [mailto:scott.marlowe@xxxxxxxxx] Gesendet: Mittwoch, 14. Juli 2010 05:33 An: Craig Ringer Cc: Andras Fabian; pgsql-general@xxxxxxxxxxxxxx Betreff: Re: PG_DUMP very slow because of STDOUT ?? On Tue, Jul 13, 2010 at 9:10 PM, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general