On Wed, 2006-07-05 at 00:16 +0200, Ramon van Alteren wrote: > Hi, > > I wondered if it mattered what default I/O scheduler I choose in my > kernel setup for gfs performance. > I've looking /sys/block but can't find any place to set the I/O > scheduler for my devices I run gfs off and looking at the docs it seems > that gfs uses the VFS layer in the linux kernel for it's reading & writing. > > If I'm correct that should mean that the scheduler influences > performance right? If so what one would be benficial for gfs performance > in general (if such a statement can be made) and what scheduler would be > benificial for a workload that consists of mostly writes and fairly few > reads (90% vs 10%) The io scheduler does influence GFS performance and the general rules of linux IO and filesystem tuning can be applied to GFS - e.g. if you have lots of random writes all over the disk partitions, try to avoid the schedulers that will attempt to do merging and sorting. In reality, I've never found one single io scheduler that can outperform all others in all types of IO workloads, even in mostly-write or mostly-read cases. The performance is very much dependent on individual workloads (random write, sequential writes, file size, directory setup), system configurations (memory size, disk array types, etc), and sometimes cluster and disk layouts. You have to actually experiment with or benchmark your workload before you can be sure of the choice. On the other hand, be aware of the cluster filesystem nature of GFS - that is, if you try to access the same file (or directory) from different nodes, the inter-nodes locking and sync issues must be considered. For example, if you do frequent writes on one node and mingle the writes with immediate reads (with the same file) on another node, you may see performance drop significantly. This is because the write node has to obtain an exclusive lock, write the file, and sync the changes into the disk before it can be read by other node, comparing with single node filesystem where no inter-node locking (network latency) is involved and the read could obtain its data from memory cache without actual disk IOs. -- Wendy -- Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
