All of lore.kernel.org
 help / color / mirror / Atom feed
* the perfomance of lxc is not better than kvm+virtio
@ 2012-09-06  8:47 cmcc.dylan
       [not found] ` <369c0ce8.7437.1399ac363cf.Coremail.dx10years-KN7UnAbNpbg@public.gmane.org>
  0 siblings, 1 reply; 5+ messages in thread
From: cmcc.dylan @ 2012-09-06  8:47 UTC (permalink / raw)
  To: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA


[-- Attachment #1.1: Type: text/plain, Size: 370 bytes --]

   As we all known the performance of lxc is near to native. I do a iozone test to compare the performance of lxc, kvm and kvm+virtio. Howerver,i find kvm+virtio has the best performance。
All  test enviroment is use the same configuration as  vcpu=4 and memory=2G
The results as follows
 
I don't understand why it is, please give me some help to explain this result.

[-- Attachment #1.2: iozone.png --]
[-- Type: image/png, Size: 10403 bytes --]

[-- Attachment #2: Type: text/plain, Size: 205 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: the perfomance of lxc is not better than kvm+virtio
       [not found] ` <369c0ce8.7437.1399ac363cf.Coremail.dx10years-KN7UnAbNpbg@public.gmane.org>
@ 2012-09-06  9:27   ` Kirill Korotaev
       [not found]     ` <DF13143A-64A8-459C-B415-B3E661611C2A-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
  0 siblings, 1 reply; 5+ messages in thread
From: Kirill Korotaev @ 2012-09-06  9:27 UTC (permalink / raw)
  To: cmcc.dylan
  Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org


[-- Attachment #1.1: Type: text/plain, Size: 1128 bytes --]

1. Have you used separate small partition for benchmarking? Disk performance varies about 2x times across the plate....

2. 596 and even 700MB/sec makes me think you measure not real disk I/O, but memory (cache).

3. iozone is not a trustable benchmark, it really sucks.

4. VMs may have wrong time flow inside the guest which may be slower then real wall clocks. So it takes sometimes "less" time for benchmark to complete and obviously performance results "faster".

5. VMs and containers are comparable on 1 rotational HDD. VM overhead becomes much more visible on fast SSD or SAN drives where performance can get as high as >1GB/sec.

Thanks,
Kirill


On Sep 6, 2012, at 12:47 , cmcc.dylan wrote:

>   As we all known the performance of lxc is near to native. I do a iozone test to compare the performance of lxc, kvm and kvm+virtio. Howerver,i find kvm+virtio has the best performance。
> All  test enviroment is use the same configuration as  vcpu=4 and memory=2G
> The results as follows
> 
> I don't understand why it is, please give me some help to explain this result.<iozone.png><ATT00001.c>


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4367 bytes --]

[-- Attachment #2: Type: text/plain, Size: 205 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re:Re: the perfomance of lxc is not better than kvm+virtio
       [not found]     ` <DF13143A-64A8-459C-B415-B3E661611C2A-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
@ 2012-09-06 14:01       ` cmcc.dylan
       [not found]         ` <21d457be.9cee.1399be2b299.Coremail.dx10years-KN7UnAbNpbg@public.gmane.org>
  0 siblings, 1 reply; 5+ messages in thread
From: cmcc.dylan @ 2012-09-06 14:01 UTC (permalink / raw)
  To: Kirill Korotaev
  Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org

Thanks Kirill!
 
>1. Have you used separate small partition for benchmarking? Disk performance varies about 2x times across the plate....
>
Because i'am still a novice in LXC, so what does your exactly means about "used separate small partition for benchmarking"?
Do you mean the rootfs of container mounted in a separate partition?
In my experiment, i use iozone test case of the phoronix test suite and i create a lxc instance use the xml config file as follows:
<domain type="lxc">
  <name>ubuntu_lxc</name>
  <memory>2048576</memory>
  <os>
    <type>exe</type>
    <init>/sbin/init</init>
  </os>
  <vcpu>4</vcpu>
  <clock offset="utc"/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/lib/libvirt/libvirt_lxc</emulator>
    <filesystem type="mount">
      <source dir="/var/lib/lxc/my-container/rootfs"/>
      <target dir="/"/>
    </filesystem>
    <interface type='bridge'>
          <source bridge='kvmbr0'/>
          <mac address='00:11:22:34:34:34'/>
        </interface>
  <console type="pty"/>
  </devices>
</domain>


>2. 596 and even 700MB/sec makes me think you measure not real disk I/O, but memory (cache).
i'm also think this is a results due to cache, for example page cache in the host os. Do you have some ideas bypassing memory cache?


>3. iozone is not a trustable benchmark, it really sucks.
>
Is there benchmark better than iozone  and can you give me some advice for io benchmark?
>4. VMs may have wrong time flow inside the guest which may be slower then real wall clocks. So it takes sometimes "less" time for benchmark to complete and obviously performance results "faster".
>
>5. VMs and containers are comparable on 1 rotational HDD. VM overhead becomes much more visible on fast SSD or SAN drives where performance can get as high as >1GB/sec.
I think the speed of io is the key factor that affects the vm's performance, is that right? 
Thanks for your help again!

At 2012-09-06 17:27:24,"Kirill Korotaev" <dev@parallels.com> wrote:
>1. Have you used separate small partition for benchmarking? Disk performance varies about 2x times across the plate....
>
>2. 596 and even 700MB/sec makes me think you measure not real disk I/O, but memory (cache).
>
>3. iozone is not a trustable benchmark, it really sucks.
>
>4. VMs may have wrong time flow inside the guest which may be slower then real wall clocks. So it takes sometimes "less" time for benchmark to complete and obviously performance results "faster".
>
>5. VMs and containers are comparable on 1 rotational HDD. VM overhead becomes much more visible on fast SSD or SAN drives where performance can get as high as >1GB/sec.
>
>Thanks,
>Kirill
>
>
>On Sep 6, 2012, at 12:47 , cmcc.dylan wrote:
>
>>   As we all known the performance of lxc is near to native. I do a iozone test to compare the performance of lxc, kvm and kvm+virtio. Howerver,i find kvm+virtio has the best performance。
>> All  test enviroment is use the same configuration as  vcpu=4 and memory=2G
>> The results as follows
>> 
>> I don't understand why it is, please give me some help to explain this result.<iozone.png><ATT00001.c>
>
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: the perfomance of lxc is not better than kvm+virtio
       [not found]         ` <21d457be.9cee.1399be2b299.Coremail.dx10years-KN7UnAbNpbg@public.gmane.org>
@ 2012-09-06 14:39           ` Glauber Costa
  2012-09-07  1:22           ` Zhu Yanhai
  1 sibling, 0 replies; 5+ messages in thread
From: Glauber Costa @ 2012-09-06 14:39 UTC (permalink / raw)
  To: cmcc.dylan
  Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Kirill Korotaev

On 09/06/2012 06:01 PM, cmcc.dylan wrote:
> 
> 
>> >2. 596 and even 700MB/sec makes me think you measure not real disk I/O, but memory (cache).
> i'm also think this is a results due to cache, for example page cache in the host os. Do you have some ideas bypassing memory cache?
> 
> 
Check your kvm command line. IIRC, KVM has a fully-cached mode of
operation. Writes to guest "disk" will not actually reach the disk for a
while. While this is nice, this is an unfair comparison from a benchmark
PoV, because of you are, of course, trading away a bit of your
data-safety. It is still safe against guest power-off, but not
necessarily against host power-off. Also, since there is no magic, this
can hurt you in very dense scenarios.

The "-drive" parameter will probably have a "cache" specifier, which is
what you are looking for.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Re: the perfomance of lxc is not better than kvm+virtio
       [not found]         ` <21d457be.9cee.1399be2b299.Coremail.dx10years-KN7UnAbNpbg@public.gmane.org>
  2012-09-06 14:39           ` Glauber Costa
@ 2012-09-07  1:22           ` Zhu Yanhai
  1 sibling, 0 replies; 5+ messages in thread
From: Zhu Yanhai @ 2012-09-07  1:22 UTC (permalink / raw)
  To: cmcc.dylan
  Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Kirill Korotaev

>>3. iozone is not a trustable benchmark, it really sucks.
>>
> Is there benchmark better than iozone  and can you give me some advice for io benchmark?

I'd prefer fio (http://git.kernel.org/?p=linux/kernel/git/axboe/fio.git;a=summary)

-zyh

>>4. VMs may have wrong time flow inside the guest which may be slower then real wall clocks. So it takes sometimes "less" time for benchmark to complete and obviously performance results "faster".
>>
>>5. VMs and containers are comparable on 1 rotational HDD. VM overhead becomes much more visible on fast SSD or SAN drives where performance can get as high as >1GB/sec.
> I think the speed of io is the key factor that affects the vm's performance, is that right?
> Thanks for your help again!
>
> At 2012-09-06 17:27:24,"Kirill Korotaev" <dev@parallels.com> wrote:
>>1. Have you used separate small partition for benchmarking? Disk performance varies about 2x times across the plate....
>>
>>2. 596 and even 700MB/sec makes me think you measure not real disk I/O, but memory (cache).
>>
>>3. iozone is not a trustable benchmark, it really sucks.
>>
>>4. VMs may have wrong time flow inside the guest which may be slower then real wall clocks. So it takes sometimes "less" time for benchmark to complete and obviously performance results "faster".
>>
>>5. VMs and containers are comparable on 1 rotational HDD. VM overhead becomes much more visible on fast SSD or SAN drives where performance can get as high as >1GB/sec.
>>
>>Thanks,
>>Kirill
>>
>>
>>On Sep 6, 2012, at 12:47 , cmcc.dylan wrote:
>>
>>>   As we all known the performance of lxc is near to native. I do a iozone test to compare the performance of lxc, kvm and kvm+virtio. Howerver,i find kvm+virtio has the best performance。
>>> All  test enviroment is use the same configuration as  vcpu=4 and memory=2G
>>> The results as follows
>>>
>>> I don't understand why it is, please give me some help to explain this result.<iozone.png><ATT00001.c>
>>
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-09-07  1:22 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-06  8:47 the perfomance of lxc is not better than kvm+virtio cmcc.dylan
     [not found] ` <369c0ce8.7437.1399ac363cf.Coremail.dx10years-KN7UnAbNpbg@public.gmane.org>
2012-09-06  9:27   ` Kirill Korotaev
     [not found]     ` <DF13143A-64A8-459C-B415-B3E661611C2A-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-09-06 14:01       ` cmcc.dylan
     [not found]         ` <21d457be.9cee.1399be2b299.Coremail.dx10years-KN7UnAbNpbg@public.gmane.org>
2012-09-06 14:39           ` Glauber Costa
2012-09-07  1:22           ` Zhu Yanhai

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.