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
Description: This is a digitally signed message part.