OpenVZ Forum - RDF feed
type: channel
items: Guaranteed CPU shares?
items: Re: Guaranteed CPU shares?

Guaranteed CPU shares?
type: item
description: I must admit that I've never had to hunt down particular performace straits before, so I'm very much a newbie on this. I have an Asterisk running in a VE running on a Quad Core Node. Yesterday, I setup a kvm to test my changes to vzdump . In phases with high virtual network traffic, the VoIP Quality went down drastically. The network traffic went from the kvm through a bridge into veth to the OpenVZ VE hosting the apt-proxy. So no physical network traffic. The VoIP traffic runs from the phone through eth0 into the veth of the VE into Asterisk, which uses chan_capi on an active card to connect to ISDN. So the net CPU load would be transcoding VoIP to ulaw (or whatever chan_capi is fed with). I'm actually not sure whether the bottleneck is in the firewall on the HW node, collisions in veth, etc. or if in the end the Asterisk VE does not get enough CPU. Could anyone give me some idea, how to tackle down the issue? Regards, - lars.
creator: laotse
date: 2009-07-27T13:05:43-00:00

Re: Guaranteed CPU shares?
type: item
description: The net CPU load would be transcoding VoIP to ulaw? The VoIP traffic runs from the phone through eth0 into the veth of the VE into Asterisk. So how is it? _________________ Call center software
creator: spikeinin
date: 2009-08-11T11:53:54-00:00

Re: Guaranteed CPU shares?
type: item
description: spikeinin wrote on Tue, 11 August 2009 13:53 The net CPU load would be transcoding VoIP to ulaw? The VoIP traffic runs from the phone through eth0 into the veth of the VE into Asterisk. So how is it? The node is a 3 GHz Quad-Core. The transcoding ran smoothly on my old 800 MHz System using a passive ISDN card, i.e. the CPU had to deal with building the S0 waveforms, too. So transcoding should not even claim a single core. Spend another core for VE0 and the idling containers and yet another one for the kvm, which should be overkill in all cases (the average load of the machine is virtually 0). And yet there's still one spare core. Giving it another thought, the issue may also be caused by a lack of memory bandwidth. But this is just cheap guessing. So my question is: Is there a systematic method, to find out, where the bottleneck occurs?
creator: laotse
date: 2009-08-11T21:25:09-00:00

Re: Guaranteed CPU shares?
type: item
description: Hi, I didn't understand your configuration clearly. Quote: So no physical network traffic. The VoIP traffic runs from the phone through eth0 into the veth of the VE into Asterisk Do you distinguish network traffic and VoIP traffic? Anyway, are there huge load average values on a system in phases with high network traffic? Could you please gather Cpu(s) information with help of "top" utility? What /proc/net/sockstat output as well as /proc/user_beancounters output? Are there any messages in dmesg or in logs?
creator: maratrus
date: 2009-08-13T07:37:14-00:00

Re: Guaranteed CPU shares?
type: item
description: maratrus wrote on Thu, 13 August 2009 09:37 Do you distinguish network traffic and VoIP traffic? No. What I wanted to make clear was that VoIP is physical traffic from the phone to the machine. But the upgrade running to the kvm instance only produced virtual network traffic from a VE running apt-proxy to the KVM instance on the same node. In short: Ethernet congestion cannot be accounted for the issue. I'll dive into the analysis following my short holidays. My work on vzdump blocked all my capacities lately. Thanks for the hints so far.
creator: laotse
date: 2009-08-17T08:26:59-00:00