Simon Banton wrote: > > >What is the recurring performance problem you are seeing? > > Pretty much exactly the symptoms described in > http://bugzilla.kernel.org/show_bug.cgi?id=7372 relating to read > starvation under heavy write IO causing sluggish system response. > > I recently graphed the blocks in/blocks out from vmstat 1 for the > same test using each of the four IO schedulers (see the PDF attached > to the article below): > > http://community.novacaster.com/showarticle.pl?id=7492 > > The test was: > > dd if=/dev/sda of=/dev/null bs=1M count=4096 &; sleep 5; dd > if=/dev/zero of=./4G bs=1M count=4096 & Hmmmm, with that workload I think your going to see performance issues no matter what, as it is using really big request sizes and it it reads into /dev/sda for 5 seconds, then at some offset starts writing a large file and both are sequential, so it is going to turn the io into 1MB random reads and writes which on SATA disks is really going to suck badly (actually it'll suck on any disk). Each request is atomic so it will not start servicing another io request until the current 1MB io request is complete, which is a long time in computer terms. Try running the same benchmark but use bs=4k and count=1048576 This will use 4k request size, avg VFS io size, and do it up to 4GB. IO will still end up random but the inter-request latency should be smaller which should provide for a better result. While these tests are running can you run any processes on another session? How about file system use while running? <snip> ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.