[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] Re: XEN - networking and performance

  • To: xen-users <xen-users@xxxxxxxxxxxxxxxxxxx>
  • From: fpt stl <fptstl@xxxxxxxxx>
  • Date: Fri, 7 Oct 2011 15:21:41 -0500
  • Delivery-date: Fri, 07 Oct 2011 13:23:35 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

Thanks for your reply.

The copy is a plain cp and the files are around 100k - 200k each, with some gzip archives as well.

So, if I understand correctly, if a DomU (VM) has attached several disks/xvd's (LVs in Dom0 storage space) then the Dom0 or Xen hypervisor is responsible for moving the data between the DomU disks.

Alternately, if the DomU has just one xvd (a larger LM in Dom0 storage space) then only DomU's allocated resources will be used. 

The second sounds better in terms or resource allocation at least. Converting several LVs which are attached to one DomU VM into one larger LV might create some performance improvement.

Please correct me if I am wrong.


-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Simon Hobson
Sent: Friday, October 07, 2011 2:47 PM
To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] Re: XEN - networking and performance

Jeff Sturm wrote:

>Anyone tried SSD with good results?  I'm sure capacity requirements can

>make it cost-prohibitive for many.

Interesting that a product I recall from 'some years ago' doesn't seem to have popped up again - or perhaps it has and I never noticed since I'm not into high end storage. This device looked to the host like a standard SCSI disk, but internally it had a load of DRAM, a small (2 1/2" ?) disk, a controller, and a small battery.

Basically it was a big RAM disk with a SCSI interface, but when the power went off it would write everything to disk. I suspect it probably had a continuous process of writing dirty blocks to disk.

Mind you, I suppose RAM does still cost somewhat more than disk.


fpt stl wrote:

>>  Also, copying 8 GB of data from one disk to another takes 50

>>(fifty) minutes !!! - both LVMs attached separately to the DomU as two

>>independent volumes [xvda - /dev/mapper/VG1-VM1 and xvdb -



>Unfortunately, at this point I cannot reconfigure the host's storage.

>But what would be the course of action taking in consideration the

>exiting storage configuration? Any tips to improve performance? 50

>minutes for 8GB is rather slooooow.


What is most likely happening here is that while your OS sees the storage as two devices, in fact they are on the same disk (or set of disks). So the copy becomes :

read a bit - seek - write a bit - seek write some metadata - seek - read a bit - seek - write a bit ...

That's a lot of seeking and seeks kill performance really badly.


It also depend son what that 8G is. A small number of big files stands a half decent chance of using some write cache to buffer some of the seeks, but if it's lots of small files then there'll be a huge amount of filesystem metadata to be updated as well.


And it also depend on what you are using for the copy. Some programs (such as dd and cpio) allow you to set a blocksize. Increasing this as far as your memory allows will help as that would mean reading a big chunk of data before seeking elsewhere to write it. Less seeks = better performance.



Simon Hobson


Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed

author Gladys Hobson. Novels - poetry - short stories - ideal as

Christmas stocking fillers. Some available as e-books.


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.