Arjen van der Meijden <acmmailing@xxxxxxxxxxxx> wrote: > On 9-4-2009 16:09 Kevin Grittner wrote: >> I haven't benchmarked it, but when one of our new machines seemed a >> little sluggish, I found this hadn't been set. Setting this and >> rebooting Linux got us back to our normal level of performance. > > Why would you reboot after changing the elevator? For 2.6-kernels, > it can be adjusted on-the-fly for each device separately > (echo 'deadline' > /sys/block/sda/queue/scheduler). On the OS where this happened, not yet an option: kgrittn@DBUTL-PG:~> cat /proc/version Linux version 2.6.5-7.315-bigsmp (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Wed Nov 26 13:03:18 UTC 2008 kgrittn@DBUTL-PG:~> ls -l /sys/block/sda/queue/ total 0 drwxr-xr-x 2 root root 0 2009-03-06 15:27 iosched -rw-r--r-- 1 root root 4096 2009-03-06 15:27 nr_requests -rw-r--r-- 1 root root 4096 2009-03-06 15:27 read_ahead_kb On machines built more recently than the above, I do see a scheduler entry in the /sys/block/sda/queue/ directory. I didn't know about this enhancement, but I'll keep it in mind. Thanks for the tip! > Apart from deadline, 'noop' should also be interesting for RAID and > SSD-owners, as it basically just forwards the I/O-request to the > device and doesn't do much (if any?) scheduling. Yeah, I've been tempted to give that a try, given that we have BBU cache with write-back. Without a performance problem using elevator, though, it hasn't seemed worth the time. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
