On Thu, Oct 19, 2006 at 03:54:28PM +0200, Tobias Brox wrote:
> I just came to think about /proc/sys/swappiness ...
>
> When this one is set to a high number (say, 100 - which is maximum), the
> kernel will aggressively swap out all memory that is not beeing
> accessed, to allow more memory for caches. For a postgres server, OS
> caches are good, because postgres relies on the OS to cache indices,
> etc. At the other hand, for any production server it's very bad to
> experience bursts of iowait when/if the swapped out memory becomes
> needed - particularly if the server is used for interactive queries,
> like serving a web application.
>
> I know there are much religion on this topic in general, I'm just
> curious if anyone has done any serious thoughts or (even better!)
> experimenting with the swappiness setting on a loaded postgres server.
I think it'd be much better to experiment with using much larger
shared_buffers settings. The conventional wisdom there is from 7.x days
when you really didn't want a large buffer, but that doesn't really
apply with the new buffer management we got in 8.0. I know of one site
that doubled their performance by setting shared_buffers to 50% of
memory.
Something else to consider is that many people will put pg_xlog on the
same drives as the OS (and swap). It's pretty important that those
drives not have much activity other than pg_xlog, so any swap activity
would have an even larger than normal impact on performance.
> I would assume that the default setting (60) is pretty OK and sane, and
> that modifying the setting would have insignificant effect. My
> religious belief is that, however insignificant, a higher setting would
> have been better :-)
>
> We're running linux kernel 2.6.17.7 (debian) on the postgres server, and
> our memory stats looks like this:
> total used free shared buffers cached
> Mem: 6083M 5846M 236M 0 31M 5448M
> -/+ buffers/cache: 366M 5716M
> Swap: 2643M 2M 2640M
>
> In addition to the postgres server we're running some few cronscripts
> and misc on it - nothing significant though.
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)