From: Tobias Brox <tobias@nordicbet.com>
To: pgsql-performance@postgresql.org
Subject: Swappiness setting on a linux pg server
Date: Thu, 19 Oct 2006 15:54:28 +0200
Message-ID: <20061019135428.GD20328@oppetid.no> (raw)
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 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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tobias@nordicbet.com
Subject: Re: Swappiness setting on a linux pg server
In-Reply-To: <20061019135428.GD20328@oppetid.no>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox