[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-API] delays with network traffic
- To: George Shuklin <george.shuklin@xxxxxxxxx>
- From: Ilya Kalinin <lidenskap@xxxxxxxxx>
- Date: Wed, 27 Apr 2011 00:00:53 +0400
- Bcc: xen-api@xxxxxxxxxxxxxxxxxxx
- Cc:
- Delivery-date: Sat, 30 Apr 2011 17:23:25 -0700
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=bcc:mime-version:in-reply-to:references:date:message-id:subject :from:to:content-type; b=ddw40FsEAkqohB4EUcksib/HmO8A0sKh59r3QN05T3/rMEoJY7q8pq5K5zzyNRUPDb BB9bNNeduDlpInglT1gdYJ2e6+0gTjcHAr8uAuo/U9Ei5YA6Z0KaY75p1ZuVdp+hWlHM tkzYxBYLyauSDbjuRc+HkOIYfWnKOhYRGOi6Y=
- List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
Actually it doesn't refer to ping intervals, got the same effect with any delay. The issue is about slowing the network performance down on both DomU and Dom0 when doing *anything* with Dom0. I think the problem is newer started processes has a higher PRI value, which is immediate priority (PRI). You can see it by doing "ps ax --format uname,pid,cmd,pri".
PRI often gets a boost (i.e. lower value) when a process is
being restarted after blocking on I/O, and conversely is lowered
(higher value) if it uses up its scheduler-assigned time slot without
blocking, at least with the standard scheduler. Many systems have
alternative schedulers with different behaviors, but in all cases PRI
is the actual current priority that the scheduler has assigned; this
value is influenced by, but not defined by, the assigned "niceness".
2011/4/25 George Shuklin <george.shuklin@xxxxxxxxx>
Good day.
Found strange behavior with xapi and guest network traffic. If we starts
to ping domU with high speed (about 3-4 pings per second) and do some
operations with xapi (f.e. xe vm-list, etc) we can see delays in pings
(up to 80 ms compare to usual 0.3-0.8). All guest are PVs.
I dig pretty much about this and found:
1) raising nice number for xenstored (nice 10, nice 20) make delays
lower.
2) Pinning dom0 and adding VCPU to dom0 slightly helps, but not
significantly.
3) switching to bridge instead ovs makes things worse (but not really
much).
4) CPU load in domU does not change behavior (not better, not worse)
5) High network and disk activity for domU make it replays sometimes
longer (up to 100ms with average load < 0.5)
In some tests I was able to get ping about 5-6ms instead 0.3-0.8 just by
running python (without options).
I feel I miss something or do not understand.
---
wBR, George.
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
--
С уважением,
Калинин Илья.
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
|
