WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re[2]: [Xen-users] poor IO perfomance

To: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Subject: Re[2]: [Xen-users] poor IO perfomance
From: Vitaliy Okulov <vitaliy.okulov@xxxxxxxxx>
Date: Wed, 30 May 2007 19:07:19 +0400
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 30 May 2007 08:04:08 -0700
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:x-mailer:reply-to:x-priority:message-id:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding; b=VHvROgvZws1R+AWlixsq3BU1qb5USv5GmLjQPvC2nZko730wnMijKti+7ms/2r4sx+jC/vJLABih65M+tUoyEBL3tbcuIXUlt95Ar49NK91vNKJf0dHpe0tW/EiGJW1XmqHmMbE/sv49JWr/aCG3BzrC+kztg6viP+xLQlSjv+o=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:x-mailer:reply-to:x-priority:message-id:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding; b=PMhSO4ijJvX/KHVuKStR1L8KTiwHxo+Bp7wIZSAAFQchDZq2I2oYB3m2DvPRGLm+vaJ6O28HSrJ7xiCYr8o/uTJjpAELXn9qFV0wGvTftBejLk71jAIy0lmwdRJD0VdJ+yU3ODXha2m8poNvnI/4Anl3Dw+ONwInrXsU2RpbWFE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <907625E08839C4409CE5768403633E0B02561D70@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <86805995.20070530161117@xxxxxxxxx> <907625E08839C4409CE5768403633E0B02561D70@xxxxxxxxxxxxxxxxx>
Reply-to: Vitaliy Okulov <vitaliy.okulov@xxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Здравствуйте, Mats.

Вы писали 30 мая 2007 г., 16:22:54:

>  

>> -----Original Message-----
>> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
>> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
>> Vitaliy Okulov
>> Sent: 30 May 2007 13:11
>> To: xen-users@xxxxxxxxxxxxxxxxxxx
>> Subject: [Xen-users] poor IO perfomance
>> 
>> Здравствуйте, xen-users.
>> 
>> Just test domU IO perfomance:
>> 
>> sda1 configure via phy:/dev/sdb1. Benchmark with dbench 
>> (dbench -D /usr/src -s 10
>> -t 120) - 102 Mb/s
>> 
>> Native sistem (mount /dev/sdb1 /mnt && dbench -D /mnt -s 10 -t 120) -
>> 140 Mb/s
>> 
>> How i can speedup dbench?

> Probably not that easy. If you have multiple disk-controllers (that
> is, multiple devices according to for example "lspci"), you can give
> one device to the guest, that should give the same performance as
> native (assuming nothing else interferes with DomU - if two domains
> share the same CPU it would of course not give the same performance as 
> native, for example).

I test native linux kernel 2.6.18-4 and get 140 Mb/s
Test xen 2.6.18-4-xen dom0 and get 127 Mb/s
I test 1 xen 2.6.18-4-xen domU and get 102 Mb/s

I think its very bad & according to official Xen benchmark IO must be
close to native.

Same controller, adaptec 2130 slp, same scsi hdd.

Also, when i use sda1 in domU as file, i recive 140 Mb/s.


> The disk-IO request goes through Dom0 even if the device is "phy:",
> as the device that is connected to "/dev/sdb1" is on a
> disk-controller owned by Dom0, so there will be some latency
> overhead, and unless the "queue" is of infinite length, that latency will 
> affect the transfer rate.

> You have to understand that any form of virtualization does add
> overhead - a bit like the raw disk-write performance is (or should
> be) higher than if you write to the disk with a file-system - but I
> don't think anyone would prefer to refer to their e-mails or
> documents by saying "please give me blocks 12313287, 12241213 and
> 12433823" instead of "/usr/doc/mytext.doc" - so the overhead is
> "accepted" because it makes the system more usable. In the
> virtualization case, there is usually a REASON for wishing to use
> virtualization: either that the system is underutilized, which means
> that it's CPU and IO capacity isn't used to full potential. Merging
> two systems that have about 20-30% utilization would still give some
> "spare" for expansion as well as for the virtualization overhead. 

> --
> Mats
>> 
>> -- 
>> С уважением,
>>  Vitaliy                          mailto:vitaliy.okulov@xxxxxxxxx
>> 
>> 
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-users
>> 
>> 
>> 




-- 
С уважением,
 Vitaliy                          mailto:vitaliy.okulov@xxxxxxxxx


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>