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/
Home Products Support Community News


Re: [Xen-users] Re: Performance Issues: I/O Wait

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Re: Performance Issues: I/O Wait
From: "Steve Senator (Senator Ent)" <sts@xxxxxxxxxxx>
Date: Tue, 23 Oct 2007 21:17:32 -0600
Cc: Nick Couchman <Nick.Couchman@xxxxxxxxx>
Delivery-date: Mon, 29 Oct 2007 10:02:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <471E3E2D020000990001D6CF@xxxxxxxxxxxxxxxxxxxxx>
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: <471E3E2D020000990001D6CF@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Internet Messaging Program (IMP) H3 (4.1.3)
Xen can exacerbate Linux SMP issues. Do you have hyperthreading turned on in your CPU's? If so, at least for testing, try turning it off.

Also, beyond turning of the TX offloading in both the dom0 and domU, is there any chance that there's another device attached to that bridge which would cause network delays? In particular, is there a device that may incorrectly see the domU IP as coming from the dom0 due to an ARP conflict? I see that you've specified a fixed MAC address. Is there any chance that that same MAC address is used by the dom0? Perhaps the initrd is the one from dom0 and its got the MAC address set in the initrd to be the same as the one in the dom0?

Try tcpdumping from both domains and see if you see any retransmissions, or perhaps even a smoking gun like a system ARPing for itself when it should know better.

It's also possible that there's a transmission size problem. There have been reported problems of dom0<->domU traffic not honoring the MTU of the bridge or virtual device, which then forces retransmission when the receiving side cannot handle the larger buffer.

If NFS, try changing from TCP to UDP or modifying the rsize and wsize buffering to fit within the MTU of your (virtual) ethernet devices.

Hope this helps,
-Steve Senator

Quoting Nick Couchman <Nick.Couchman@xxxxxxxxx>:

Hi, again...haven't had any responses to this, yet.

Nick Couchman 10/18/07 11:05 AM >>>
Hey, everyone,
I'm having some issues with a Xen DomU right related to performance. ... The culprit seems to be high I/O wait times related to the network interface.

The host machine is a Dell PowerEdge 1950 with 2 x Dual-Core Xeon processors (Xeon 5150 @ 2.66GHz, 1333 FSB). ... Building these Linux distributions on the physical system takes 70-80 minutes (real time) - on the DomU system it takes 130-140 minutes.
vif=[ 'mac=00:16:3e:75:0d:be,bridge=xenbr108', ]

Xen-users mailing list