4285ch04.fm Draft Document for Review May 4, 2007 11:35 am
120 Linux Performance and Tuning Guidelines
I
Figure 4-10 Impact of nr_requests on the CFQ elevator (random write Ext3)
It is important to point out that the current enterprise distributions from Red Hat and Linux
offer the possibility to set nr_requests on a per disk subsystem basis. Hence I/O access
patterns can be isolated and optimally tuned. An example would be a database system where
the log partitions and the database would be stored on a dedicated disks or disk subsystems
(such as a storage partition on a DS8300). In this example it would be beneficial to use a
large nr_reuests for the log partition that has to accommodate a large number of small write
I/Os and a smaller value for the database partition that might see read I/Os as large as
128kB.
Impact of read_ahead_kb
In the case of large streaming reads, increasing the size of the read ahead buffer may
increase performance yet more. Remember though that increasing this value will not increase
performance for most server workloads as these are mainly random I/O operations. The value
in read_ahead_kb defines how large read ahead operations can be. The value stored in
/sys/block/<disk_subsystem>/queue/read_ahead_kb defines how large the read operations
may be in kB. The value can be parsed or changed using for instance the cat or echo
command as indicated in Example4-14.
Example 4-14 Parsing and setting the size of read ahead operations
# cat /sys/block/<disk_subsystem>/queue/read_ahead_kb
# echo 64 > /sys/block/<disk_subsystem>/queue/read_ahead_kb
Tip: In order to find out how to measure and calculate the average I/O size, please refer to
2.3.6, “iostat” on page 48.
0
20000
40000
60000
80000
100000
120000
140000
kB/sec
4 8 16 32 64 128 256 512 1024 2048
kB/op
cfq 128 nr_requests
cfq 2048 nr_requests
cfq 64 nr_requests
cfq 8192 nr_requests