Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 29

Thread: KVM Virtualization Performance With Linux 2.6.31

  1. #11
    Join Date
    Jun 2008
    Posts
    7

    Default

    Quote Originally Posted by phoronix View Post
    Phoronix: KVM Virtualization Performance With Linux 2.6.31

    Earlier this month at the Red Hat Summit where Red Hat Enterprise Linux 5.4 was released with support for the Kernel-based Virtual Machine. At this Red Hat event, virtualization -- particularly KVM -- and cloud computing were the most talked about topics. But how is KVM performing these days? With new virtualization refinements going into almost every new Linux kernel release, we have published a new set of KVM benchmarks using the Linux 2.6.31 kernel, to provide updated numbers against our KVM benchmarks from last year and our Core i7 virtualization numbers. This time around, we are also using a Phenom II processor for testing out the AMD-V technology.

    http://www.phoronix.com/vr.php?view=14201
    Would it be possible for you to test RHEL 5.4, so its possible to compare the two ? (the talk from redhat mentions the disk i/o as one of the key aspects they're trying to improve - and some changes have already made it into 5.4.)

  2. #12
    Join Date
    Jun 2009
    Location
    Elsewhere
    Posts
    90

    Default

    Hi.

    I would have been much more interested in how a virtual machine performs with paravirtualized guest drivers -- unless this is what was actually done as there is no mention of using paravirtualized or virtio drivers at all.

  3. #13

    Default

    Quote Originally Posted by nanonyme View Post
    Wrong, according to the test SQLite ran magnitudes better under VM that native. Most CPU-intensive tasks were just as fast under VM, most hard-disk-intensive tasks were slower under VM. This would imo hint towards a need to develop better virtualization technology for hard disks.
    Wrong.
    SQLite didn't run faster under VM than native.
    You're just seeing misleading results because the host was caching.

  4. #14
    Join Date
    Sep 2007
    Location
    Germany
    Posts
    99

    Default

    Quote Originally Posted by nanonyme View Post
    Wrong, according to the test SQLite ran magnitudes better under VM that native. Most CPU-intensive tasks were just as fast under VM, most hard-disk-intensive tasks were slower under VM. This would imo hint towards a need to develop better virtualization technology for hard disks.
    If you were right, everybody would run his/her database in a VM in a VM in a VM...

  5. #15
    Join Date
    Sep 2009
    Posts
    1

    Default Seriously Michael, are you on crack?

    How can you test the IO performance of a virtualized Linux host and not use virtio? It is akin to testing the top speed of a porsche on the spare doughnut... It makes 0 sense.

    Can you do some honest benchmarking and use virtio? These numbers are completely ignorant at best. If you want good IO on kvm, you use the paravirt drivers.

  6. #16
    Join Date
    Jun 2006
    Posts
    311

    Default

    Quote Originally Posted by SEJeff View Post
    How can you test the IO performance of a virtualized Linux host and not use virtio? It is akin to testing the top speed of a porsche on the spare doughnut... It makes 0 sense.

    Can you do some honest benchmarking and use virtio? These numbers are completely ignorant at best. If you want good IO on kvm, you use the paravirt drivers.
    I don't agree with you.

    Someone lay person who is examining comparitive results are the target for most of Phoronix articles. The key is "available at arms length" benchmarking, ie: easily available - out of the box.

    If you want to create a recipe that shows KVM to the the best capability, can I suggest the following

    1) Identify all the steps needed for the tuned setup
    2) Create a fully described list of directions for building the tuned setup
    3) Execute the list, keeping track of the length of time to do it.
    4) Repeat the benchmark (Michael can probably supply a PTS test suite to do so)
    5) Post the collection here.

    I'd be interested to see the effort and results.

  7. #17
    Join Date
    Jun 2006
    Posts
    311

    Default

    Quote Originally Posted by ian.woodstock View Post
    Wrong.
    SQLite didn't run faster under VM than native.
    You're just seeing misleading results because the host was caching.
    The SQLite test was faster under the VM.

    Although I don't have explicit information on the benchmark, it would appear that the VM is doing the operations synchronously (similar to the native execution), but the VM's disk driver is caching and batching the writes.

    This would result in a faster experience under a VM, however you risk data integrity that you don't risk in the native position.

    I would expect that it is a possible bug in the KVM driver stack, however the any SQLite based application would experience the performance boost.

    So this sort of benchmarking does show extreme value and doesn't mislead. It highlights a questionable delta between Host and Guest, and consequently requires deeper examination.

    The net result is that currently, out of the box KVM support is slow for most operations except some CPU bound operations, but even more concerning it potentially risks data by not making synchronous IO operations asynchronous.

    Regards,

    Matthew
    Last edited by mtippett; 09-22-2009 at 09:50 PM. Reason: Added "a" to asynchronous in the last sentence.

  8. #18
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,604

    Default

    Quote Originally Posted by mtippett View Post
    The net result is that currently, out of the box KVM support is slow for most operations except some CPU bound operations, but even more concerning it potentially risks data by not making synchronous IO operations synchronous.
    Seems I interpreted IO wrong then. But yeah, I do agree that KMV is likely slower for most operations. (covering real-life usage that this test was related to only slightly) The virtualization extensions should only really be helpful for the CPU bound operations as far as I've understood.
    I'd have assumed native should cache and batch too though unless you explicitly flush.

  9. #19
    Join Date
    Feb 2009
    Posts
    7

    Default

    Quote Originally Posted by nanonyme View Post
    Wrong, according to the test SQLite ran magnitudes better under VM that native. Most CPU-intensive tasks were just as fast under VM, most hard-disk-intensive tasks were slower under VM. This would imo hint towards a need to develop better virtualization technology for hard disks.
    If you LD_PRELOAD a library that implements fsync() as a no-op, you can get the same speedup on the host, without virtualization! I suggest you use this handy library someone provided. Heck, it might be better to just patch your glibc and not mess with pesky preloading. Instant speedup!

    You obviously don't know what you're talking about. Read a little. Actual technical stuff, not "benchmarks" done by a monkey trained to run the single-click "suite" without knowing what is measured or what it means.

    For the record, that result just means all their numbers are invalid and completely useless.

  10. #20
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,604

    Default

    Quote Originally Posted by wolf550e View Post
    You obviously don't know what you're talking about. Read a little. Actual technical stuff, not "benchmarks" done by a monkey trained to run the single-click "suite" without knowing what is measured or what it means.
    That single case was brought up as a peculiarity, not as a recommendation to use SQLite under VM. It kinda jumps up when you've immensively better results in VM than native, that's what I meant with that first bit. It was a single case where VM seemed faster so I picked it up. Naturally native being tons faster than VM is uninteresting (except for CPU-bound tasks) since it's expected. What I continued with was that I intuitively assumed that reading an SQLite database file inside an image file on the hard disk would be slower than just reading a file on the hard disk. (on latter thoughts I'm not even sure if this matters, might not even significantly increase fragmentation)
    Also read my message again: My conclusion was that virtual I/O needs to develop, not that real I/O needs to take example of virtual I/O. Even though the basis for my conclusion was wrong, the conclusion was apparently right.
    Last edited by nanonyme; 09-23-2009 at 05:42 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •