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@xxxxxxxxx EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
