Date: Wed, 04 May 2011 22:55:26 -0700 From: Ted Mittelstaedt <tedm@mittelstaedt.us> To: John <aqqa11@earthlink.net> Cc: freebsd-emulation@freebsd.org Subject: Re: virtualbox I/O 3 times slower than KVM? Message-ID: <4DC23BCE.8030007@mittelstaedt.us> In-Reply-To: <17339409.1304573629442.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> References: <17339409.1304573629442.JavaMail.root@elwamui-royal.atl.sa.earthlink.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/4/2011 10:33 PM, John wrote: > > > > -----Original Message----- >> From: Ivan Voras<ivoras@freebsd.org> Sent: May 4, 2011 7:36 AM To: >> freebsd-emulation@freebsd.org Subject: Re: virtualbox I/O 3 times >> slower than KVM? >> >> On 03/05/2011 20:25, John wrote: >> >>> What I do is to cat the 330MB binary file (XP service pack from >>> Microsoft) 20 times into a single 6.6GB file, "date" before and >>> afterwards, and after the second date finishes, immediately Force >>> power shut down. There are two observations: >>> >>> 1. the time to complete copying into this 6.6GB file were 72s, >>> 44s, 79s in three runs, presumably because there is another >>> production VM on the same host. The average is 65s, so it's >>> about 100MB/s. 2. After immediately power down, I do found the >>> resulting file was less than 6.6GB. So indeed the VM claimed the >>> completion of the copying before it actually did. >>> >>> I then did the same thing on the virtualbox, since I don't want >>> the above premature I/O, I made sure the "Use Host I/O cache" is >>> unchecked for the VM storage. >>> >>> 1. the time to complete copying into this 6.6GB file was 119s and >>> 92s, the average is 105s, so the speed is 62MB/s. 2. after >>> immediately "Reset" the machine, I couldn't boot. Both times it >>> asked me to do fsck for that partition (GPT 2.2T). But after >>> finally powering up, I found the file was also less than 6.6GB >>> both times as well. >>> >>> So looks like virtualbox also suffers caching problem? Or did I >>> do anything wrong? >> >> Aaargh. Please don't invent benchmarks. The ones which are already >> around have enough troubles by themselves. >> >> Instead, if you really want to do a proper comparison of the >> systems, do this (in the order I've written): >> >> 1) add these lines to /etc/sysctl.conf: >> >> vfs.hirunningspace=8388608 vfs.lorunningspace=6291456 >> vfs.read_max=128 >> >> 2) configure the FreeBSD system to use AHCI >> >> http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html >> >> 3) use benchmarks/bonnie++ from ports for benchmarking. Note that >> you need to run *the same version of the benchmark* on all systems >> (i.e. also on Linux) to be able do do comparison. >> >> Any do-it-yourself benchmarks you do are very likely meaningless >> and you cannot conclude anything from them. Even with this, there >> could be *huge* differences in the results simply as a consequence >> of rotational positions of virtual drives on the physical one. See >> this results (note the transfer rate results). >> >> lara:~# diskinfo -vt /dev/ada0 /dev/ada0 512 # sectorsize >> 500107862016 # mediasize in bytes (466G) 976773168 # mediasize >> in sectors 0 # stripesize 0 # stripeoffset >> 969021 # Cylinders according to firmware. 16 # >> Heads according to firmware. 63 # Sectors according to >> firmware. 6QG3Z026 # Disk ident. >> >> Seek times: Full stroke: 250 iter in 5.671675 sec = 22.687 >> msec Half stroke: 250 iter in 4.294470 sec = 17.178 msec >> Quarter stroke: 500 iter in 6.793844 sec = 13.588 msec Short >> forward: 400 iter in 2.637252 sec = 6.593 msec Short >> backward: 400 iter in 2.320116 sec = 5.800 msec Seq outer: >> 2048 iter in 0.217796 sec = 0.106 msec Seq inner: 2048 iter >> in 0.218317 sec = 0.107 msec Transfer rates: outside: >> 102400 kbytes in 1.221390 sec = 83839 kbytes/sec middle: >> 102400 kbytes in 1.445180 sec = 70856 kbytes/sec inside: >> 102400 kbytes in 2.451970 sec = 41762 kbytes/sec >> >> Benchmarking file systems and drive IO is complicated :) >> > > Well this quickly becomes a debate on what is the most meaningful (or > meaningless) I/O benchmark, and clearly people even may not agree on > existing I/O benchmarking tools, so I'm not sure how meaningful more > test down the road will be. > > Some later discussions were quite informative, although let's not > forget the issues related to virtualbox or/and its implementation of > FreeBSD reflected from these tests. > > It's suffice to say, in the default configuration of FreeBSD (sync > mount), at least in one situation (copying a few GB files) the guest > FreeBSD of virtualbox has much slower I/O than the host FreeBSD (and > the FreeBSD guest on FreeBSD virtualbox is clearly slower than CentOS > guest on KVM CentOS, even though the FreeBSD host is slightly faster > than CentOS host), AND the guest FreeBSD is fooled into prematurely > declaring completion of writing and renders itself unable to boot > after reset. Which, I believe, defeated the proud sync mount default > of FreeBSD. > > Whether this can be a typical usage pattern, or whether there are > other situation similar (or not similar) to this is another issue. > Clearly this is related to virtualbox and its implementation on > FreeBSD. I just wish it can improve over time, since virtualbox is > the best virtualization solution on *BSD. I have run a FreeBSD guest under FreeBSD host using virtualbox for the last year, it runs an accounting package. It is a bit slower than if the OS was bare metal (the host is a dual Xeon 2.0Ghz system so there are 4 cores there - although it is only a 32 bit system) but it has never crashed or caused the host to crash. I';m pretty satisfied that there's not much to be gained in "improving" virtualbox and if I wanted a faster guest I'd buy a faster machine. Ted > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To > unsubscribe, send any mail to > "freebsd-emulation-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DC23BCE.8030007>