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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
