xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* Forking time in Xen
@ 2012-06-18  9:38 Sergey Zhukov
  2012-06-18 10:38 ` George Dunlap
  2012-06-18 11:35 ` Pasi Kärkkäinen
  0 siblings, 2 replies; 3+ messages in thread
From: Sergey Zhukov @ 2012-06-18  9:38 UTC (permalink / raw)
  To: xen-devel

Hi,

I repost this message from xen-users list following by others
subscribers suggestions:


I found an article about forking time for redis NoSQL database in
different systems:

http://redis.io/topics/latency
---------Quote------------------
Fork time in different systems
Modern hardware is pretty fast to copy the page table, but Xen is not.
The problem with Xen is not virtualization-specific, but Xen-specific.
For instance using VMware or Virutal Box does not result into slow fork
time. The following is a table that compares fork time for different
Redis instance size. Data is obtained performing a BGSAVE and looking at
the latest_fork_usec filed in the INFO command output.

      * Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds
        (12.8 milliseconds per GB).
      * Linux running on physical machine (Unknown HW) 6.1GB RSS forked
        in 80 milliseconds (13.1 milliseconds per GB)
      * Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS
        forked into 62 millisecodns (9 milliseconds per GB).
      * Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds
        (23.3 millisecond per GB).
      * Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds
        (239.3 milliseconds per GB).
      * Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecodns
        (424 milliseconds per GB).

As you can see a VM running on Xen has a performance hit that is between
one order to two orders of magnitude. We believe this is a severe
problem with Xen and we hope it will be addressed ASAP.
----------End of quote-----------------

I made my own test with Xen 4.1 and Redis 2.4 with 7.04GB dataset. The
test was performed on Intel Core I5 2500 processor unit. Forking time
was about 1 sec or 151 ms/GB - it's faster then tests over Amazon
EC2/Linode were mentioned in the article, but still much slower then
VMWare or physical machines. Has anyone running with this issue? Or may
be there is a way to tune Xen for less forking times?

Sergey Zhukov

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

* Re: Forking time in Xen
  2012-06-18  9:38 Forking time in Xen Sergey Zhukov
@ 2012-06-18 10:38 ` George Dunlap
  2012-06-18 11:35 ` Pasi Kärkkäinen
  1 sibling, 0 replies; 3+ messages in thread
From: George Dunlap @ 2012-06-18 10:38 UTC (permalink / raw)
  To: Sergey Zhukov; +Cc: xen-devel

On Mon, Jun 18, 2012 at 10:38 AM, Sergey Zhukov <svg@ngs.ru> wrote:
> Hi,
>
> I repost this message from xen-users list following by others
> subscribers suggestions:
>
>
> I found an article about forking time for redis NoSQL database in
> different systems:
>
> http://redis.io/topics/latency
> ---------Quote------------------
> Fork time in different systems
> Modern hardware is pretty fast to copy the page table, but Xen is not.
> The problem with Xen is not virtualization-specific, but Xen-specific.
> For instance using VMware or Virutal Box does not result into slow fork
> time. The following is a table that compares fork time for different
> Redis instance size. Data is obtained performing a BGSAVE and looking at
> the latest_fork_usec filed in the INFO command output.
>
>      * Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds
>        (12.8 milliseconds per GB).
>      * Linux running on physical machine (Unknown HW) 6.1GB RSS forked
>        in 80 milliseconds (13.1 milliseconds per GB)
>      * Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS
>        forked into 62 millisecodns (9 milliseconds per GB).
>      * Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds
>        (23.3 millisecond per GB).
>      * Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds
>        (239.3 milliseconds per GB).
>      * Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecodns
>        (424 milliseconds per GB).
>
> As you can see a VM running on Xen has a performance hit that is between
> one order to two orders of magnitude. We believe this is a severe
> problem with Xen and we hope it will be addressed ASAP.
> ----------End of quote-----------------
>
> I made my own test with Xen 4.1 and Redis 2.4 with 7.04GB dataset. The
> test was performed on Intel Core I5 2500 processor unit. Forking time
> was about 1 sec or 151 ms/GB - it's faster then tests over Amazon
> EC2/Linode were mentioned in the article, but still much slower then
> VMWare or physical machines. Has anyone running with this issue? Or may
> be there is a way to tune Xen for less forking times?

[Sorry -- didn't see the post on this list before I responded to your
mail on xen-users.]

Which version of the kernel are you using for Xen?  And is it a pvops
kernel or a "classic xen" kernel?

Also, have you tried running Linux in HVM mode?

The original "classic Xen" kernel had a lot of performance tuning done
to it.  But the focus of pvops development for years has just been
*getting the necessary support into the kernel*, so these kinds of
microbenchmark performance things have suffered just because no one
has been looking at it.  We've got engineers looking more closely at
this now, so it's good to know what areas we need to look at.

If you use HVM mode, you'll most likely be using the same exact
codepaths that KVM will be using (hardware pagetable virtualization),
and so will hopefully get the same speed.

 -George

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

* Re: Forking time in Xen
  2012-06-18  9:38 Forking time in Xen Sergey Zhukov
  2012-06-18 10:38 ` George Dunlap
@ 2012-06-18 11:35 ` Pasi Kärkkäinen
  1 sibling, 0 replies; 3+ messages in thread
From: Pasi Kärkkäinen @ 2012-06-18 11:35 UTC (permalink / raw)
  To: Sergey Zhukov; +Cc: xen-devel

On Mon, Jun 18, 2012 at 04:38:39PM +0700, Sergey Zhukov wrote:
> Hi,
> 
> I repost this message from xen-users list following by others
> subscribers suggestions:
> 
> 
> I found an article about forking time for redis NoSQL database in
> different systems:
> 
> http://redis.io/topics/latency
> ---------Quote------------------
> Fork time in different systems
> Modern hardware is pretty fast to copy the page table, but Xen is not.
> The problem with Xen is not virtualization-specific, but Xen-specific.
> For instance using VMware or Virutal Box does not result into slow fork
> time. The following is a table that compares fork time for different
> Redis instance size. Data is obtained performing a BGSAVE and looking at
> the latest_fork_usec filed in the INFO command output.
> 
>       * Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds
>         (12.8 milliseconds per GB).
>       * Linux running on physical machine (Unknown HW) 6.1GB RSS forked
>         in 80 milliseconds (13.1 milliseconds per GB)
>       * Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS
>         forked into 62 millisecodns (9 milliseconds per GB).
>       * Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds
>         (23.3 millisecond per GB).
>       * Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds
>         (239.3 milliseconds per GB).
>       * Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecodns
>         (424 milliseconds per GB).
> 
> As you can see a VM running on Xen has a performance hit that is between
> one order to two orders of magnitude. We believe this is a severe
> problem with Xen and we hope it will be addressed ASAP.
> ----------End of quote-----------------
> 
> I made my own test with Xen 4.1 and Redis 2.4 with 7.04GB dataset. The
> test was performed on Intel Core I5 2500 processor unit. Forking time
> was about 1 sec or 151 ms/GB - it's faster then tests over Amazon
> EC2/Linode were mentioned in the article, but still much slower then
> VMWare or physical machines. Has anyone running with this issue? Or may
> be there is a way to tune Xen for less forking times?
> 

If you need good fork-performance you should use Xen PVHVM guests, not PV.

Xen PV model needs to validate the new process page tables in the hypervisor 
every time when a fork happens, so that will have some performance hit in fork-heavy workloads.

HVM does not need to do that.. so please try switching to Xen PVHVM and benchmark again.

-- Pasi

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

end of thread, other threads:[~2012-06-18 11:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-06-18  9:38 Forking time in Xen Sergey Zhukov
2012-06-18 10:38 ` George Dunlap
2012-06-18 11:35 ` Pasi Kärkkäinen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).