Re: System overload / context switching / oom, 8.3

Rob Lemley wrote:
> here was a discussion on the postgres lists about somehow having the
> postgres distribution include the functionality to set oom_adj on
> startup. To my knowledge, that's not in 8.3 so I wrote a script and
> init.d script to do this on Debian systems.

That's not in anything earlier than the upcoming 9.0 because the support
code involved just showed up:
http://archives.postgresql.org/pgsql-committers/2010-01/msg00169.php

It was always possible to do this in an init script as you describe.
The specific new feature added is the ability to remove client child
processes from having that protection, so that they can still be killed
normally. Basically, limiting the protection just at the process that
you really need it on. The updated documentation for the new version
has more details about this whole topic, useful to people running older
versions too:
http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html

> Kind of off-topic, but a Linux kernel parameter that's often not set
> on database servers is elevator=deadline which sets up the io
> scheduling algorithm. The algorithm can be viewed/set at runtime for
> example the disk /dev/sdc in /sys/block/sdc/queue/scheduler.

I've never seen a real-world PostgreSQL workload where deadline worked
better than CFQ, and I've seen a couple where it was significantly
worse. Playing with that parameter needs a heavy disclaimer that you
should benchmark *your app* before and after changing it to make sure it
was actually useful. Actually, three times: return to CFQ again
afterwards, too, just to confirm it's not a "faster on the second run"
effect.

The important things to get right on Linux are read-ahead and reducing
the size of the write cache size--the latter being the more direct and
effective way to improve the problem that the scheduler change happens
to impact too. Those have dramatically more importance than sensible
changes to the scheduler used (with using the anticipatory one on a
server system or the no-op one on a desktop would be non-sensible changes).

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us