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@xxxxxxxxxxxxxxx www.2ndQuadrant.us -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
