On Tue, Aug 30, 2011 at 10:05 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: > On Tue, Aug 30, 2011 at 8:36 PM, mark <dvlhntr@xxxxxxxxx> wrote: >> To the broader list, regarding troubles with kswap. I am curious to what >> others seeing from /proc/zoneinfo for DMA pages (not dma32 or normal) - >> basically if it sits at 1 or not. Setting swappiness to 0 did not have any >> affect for us on kswap issues. Another thing I have not had time and >> resources to go work on... interested in what kernel they are running and >> what storage drivers they might be using. > > Well, we had zone reclaim mode autoset to 1, and we had to turn it off > to get decent performance with postgresql. Machine was a quad > dodecacore Magny Cours, so 48 cores with 128G RAM. RAID controller is > an Areca 1680 with BBU, 34 15kRPM 147G SAS Seagate 15k6 drives in two > 16 drive external enclosures and 2 drives in the server. > > The only solution we could find for kswapd going crazy was to just > turn off swap. Pretty sure I used a large swap file to test larger > swaps, but all that did was put off the eventual kswapd storm. It took > anywhere from one to two weeks, maybe more, and then one day you check > and your servers maxed out by kswapd. hm, that's an interesting counterpoint to what I've been saying. I've never seen that, I wonder what the underlying trigger was? I typically set shared_buffers fairly low (even to the default, raising only when I think it might help) -- I wonder if that plays in. to setting 1000 connections: some applications rely on database session features (like advisory locks or listen/notfiy) and retooling the client is more trouble than it's worth. This is definitely on the upper bound of what's reasonable though...these days I code with the assumption that pgbouncer is going to be put in even if I don't need it right away. merlin merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
