On Mon, 13 Apr 2009, Tim Kaufmann wrote:
With the help of Tom Brown, I've started over benchmarking dom0 and domU2 for
more realistic results. Correct me if I'm wrong, Tom, but what you
recommended was using a larger testfile (twice the size of the RAM) and
adding "conv=fsync" to the dd-command to get rid of caching effects.
In theory, either change will work... but using the big files will also
mitigate things like raid card and on-disk write caches (which fsync might
not cut through).
dom0
====
dd if=/dev/zero of=./test16384M bs=1024k count=16384 conv=fsync
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB) copied, 82,1605 s, 209 MB/s
That is still a pretty impressive number :)
time (cp test16384M test16384M2;sync)
real 3m8.108s
user 0m0.660s
sys 0m20.790s
And given your FAST write speed, that seems about right for the mixed
read/write/seek activity that copying big files will represent.
domU2
=====
dd if=/dev/zero of=./test1024M bs=1024k count=1024 conv=fsync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 184.295 s, 5,8 MB/s
time (cp test1024M test1024M2;sync)
real 3m11.915s (testfile is only 1/16 the size of testfile for dom0!)
Depending on how you have the storage for the domU setup, you might still
be getting caching in the dom0, so it is safest to stick to the full
system size, but since these numbers are so much drastically slower than
your dom0 numbers, they clearly demonstrate that there IS a bottleneck
here that is far slower than your disk subsystem... and using 16 gig would
take at least 16 times as long which is starting to get unreasonable,
especially when the "this is SLOW" point has already been made.
Anyhow, sorry for the digression. I can't remember what the numbers were
supposed to demonstrate. :)
-Tom
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home