Re: why does swap not recover? - Mailing list pgsql-performance

From Richard Yen
Subject Re: why does swap not recover?
Date
Msg-id 8D32F5BC-3E1B-45AF-AA10-DA505EFFF483@richyen.com
Whole thread Raw
In response to Re: why does swap not recover?  (Scott Carey <scott@richrelevance.com>)
List pgsql-performance
On Mar 26, 2010, at 5:25 PM, Scott Carey wrote:
> Linux until recently does not account for shared memory properly in its swap 'aggressiveness' decisions.
> Setting shared_buffers larger than 35% is asking for trouble.
>
> You could try adjusting the 'swappiness' setting on the fly and seeing how it reacts, but one consequence of that is
tradingoff disk swapping for kswapd using up tons of CPU causing other trouble. 
Thanks for the tip.  I believe we've tried tuning the 'swappiness' setting on the fly, but it had no effect.  We're
hypothesizingthat perhaps 'swappiness' only comes into effect at the beginning of a process, so we would have to
restartthe daemon to actually make it go into effect--would you know about this? 

> Either use one of the last few kernel versions (I forget which addressed the memory accounting issues, and haven't
triedit myself), or turn shared_buffers down.  I recommend trying 10GB or so to start. 

We're currently using CentOS 2.6.18-164.6.1.el5 with all the default settings.  If this is after the one that dealt
withmemory accounting issues, I agree that I'll likely have to lower my shared_buffers. 

My sysctl.conf shows the following:
> kernel.msgmnb = 65536
> kernel.msgmax = 65536
> kernel.shmmax = 68719476736
> kernel.shmall = 4294967296

BTW, I forgot to mention that I'm using FusionIO drives for my data storage, but I'm pretty sure this is not relevant
tothe issue I'm having. 

Thanks for the help!
--Richard

pgsql-performance by date:

Previous
From: Tadipathri Raghu
Date:
Subject: Optimizer showing wrong rows in plan
Next
From: Szymon Guz
Date:
Subject: Re: Optimizer showing wrong rows in plan