Emmanuel Florac put forth on 7/27/2010 5:47 AM: > Le Tue, 27 Jul 2010 11:24:52 +0200 > Matthias Schniedermeyer <ms@xxxxxxx> écrivait: > >> In case anybody has an idea what i could do to identify and/or >> isolate the root-cause, i'm open for suggestions. >> > > I'd thought that the io scheduler is the culprit. I've generally found > that the default CFQ scheduler (default) is terrible for file servers. Agreed. The scheduler may not be the cause of his issue, but switching to deadline or noop should certainly help overall I/O a bit. I'm no fan of CFQ either. I've been using deadline for quite a while and it seems to be good for local single disk and JBOD, as well as for Linux software RAID to local disks. Deadline and noop are both good choices if using a good intelligent PCI RAID controller, or if doing I/O over a FC/iSCSI HBA to a SAN controller; in fact noop probably shouldn't be used with anything but intelligent I/O controllers. My informal testing some time ago revealed that deadline will pick up some of the performance slack if you're unable to use NCQ due to a crappy SATA chipset/HBA and/or drive firmware (or both). Testing also showed that it basically ties noop when used with Qlogic 4Gb FC HBAs and IBM and Nexsan SAN array controllers. Deadline just seems to work pretty well with anything, picking up slack when lacking intelligent I/O hardware, and not really getting in the way when you have it. ** Testing will reveal which is better for a given server/storage and application mix. Such testing is why I only include deadline in my custom kernels (that and the fact I like to keep my kernels tight, as small as possible--dropping CFQ and noop simply cuts a little more dead weight from the binary). -- Stan _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
