Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id E7B449FA6AF for ; Thu, 19 Oct 2006 13:53:57 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 11246-01 for ; Thu, 19 Oct 2006 16:53:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from lynet.oppetid.no (oppetid.no [80.65.51.2]) by postgresql.org (Postfix) with ESMTP id 967CF9FA5D8 for ; Thu, 19 Oct 2006 13:53:50 -0300 (ADT) Received: by lynet.oppetid.no (Postfix, from userid 1019) id B071D11AFAA; Thu, 19 Oct 2006 18:53:49 +0200 (CEST) Date: Thu, 19 Oct 2006 18:53:49 +0200 From: Tobias Brox To: "Jim C. Nasby" Cc: Tobias Brox , pgsql-performance@postgresql.org Subject: Re: Swappiness setting on a linux pg server Message-ID: <20061019165349.GE31916@oppetid.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Group Nordicbet User-Agent: Mutt/1.5.9i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.135 tagged_above=0 required=5 tests=FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200610/409 X-Sequence-Number: 21538 [Jim C. Nasby - Thu at 11:45:32AM -0500] > > > The issue with pg_xlog is you don't need bandwidth... you need super-low > > > latency. The best way to accomplish that is to get a battery-backed RAID > > > controller that you can enable write caching on. > > > > Sounds a bit risky to me :-) > > Well, you do need to understand what happens if the machine does lose > power... namely you have a limited amount of time to get power back to > the machine so that the controller can flush that data out. Other than > that, it's not very risky. We have burned ourself more than once due to unreliable raid controllers ... > quantities of memory. So in your case, 600M wouldn't be pushing things > much at all. Even 1G wouldn't be that out of the ordinary. Also remember > that the more memory for shared_buffers, the less for > sorting/hashes/etc. (work_mem) What do you mean, a high value for the shared_buffers implicates I can/should lower the work_mem value? Or just that I should remember to have more than enough memory for both work_mem, shared_buffers and OS caches? What is a sane value for the work_mem? It's currently set to 8M.