Am Freitag, 15. Juni 2012, 10:16:02 schrieb Dave Chinner: > So, the average service time for an IO is 10-16ms, which is a seek > per IO. You're doing primarily 128k read IOs, and maybe one or 2 > writes a second. You have a very deep request queue: > 512 requests. > Have you tuned /sys/block/sda/queue/nr_requests up from the default > of 128? This is going to be one of the causes of your problems - you > have 511 oustanding write requests, and only one read at a time. > Reduce the ioscehduer queue depth, and potentially also the device > CTQ depth. Dave, I'm puzzled by this. I'd believe that a higher #req. would help the block layer to resort I/O in the elevator, and therefore help to gain throughput. Why would 128 be better than 512 here? And maybe Matthew could profit from limiting the vm.dirty_bytes, I've seen when this value is too high the server stucks on lots of writes, for streaming it's better to have this smaller so the disk writes can keep up and delays are not too long. > Oh, I just noticed you are might be using CFQ (it's the default in > dmesg). Don't - CFQ is highly unsuited for hardware RAID - it's > hueristically tuned to work well on sngle SATA drives. Use deadline, > or preferably for hardware RAID, noop. Wouldn't deadline be better with a higher rq_qu size? As I understand it, noop only groups adjacent I/Os together, while deadline does a bit more and should be able to get bigger adjacent I/O areas because it waits a bit longer before a flush. -- mit freundlichen Grüssen, Michael Monnerie, Ing. BSc it-management Internet Services: Protéger http://proteger.at [gesprochen: Prot-e-schee] Tel: +43 660 / 415 6531
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
