Re: High latencies writing to a memory mapped file

[Stan Hoeppner <stan@hardwarefreak.com>]

Emmanuel Florac put forth on 7/27/2010 5:47 AM:
> Le Tue, 27 Jul 2010 11:24:52 +0200
> Matthias Schniedermeyer <ms@citd.de> é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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs