On Tue, Aug 30, 2011 at 10:05 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
> On Tue, Aug 30, 2011 at 8:36 PM, mark <dvlhntr@gmail.com> 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
