OpenVZ Forum: Support » Guaranteed CPU shares?

Home » General » Support » Guaranteed CPU shares?

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Guaranteed CPU shares? [message #36885]

Mon, 27 July 2009 13:05

laotse
Messages: 35
Registered: December 2008

Member

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 Wink

. 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.

Report message to a moderator

Re: Guaranteed CPU shares? [message #37010 is a reply to message #36885]

Tue, 11 August 2009 11:53

spikeinin
Messages: 1
Registered: August 2009

Junior Member

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

Report message to a moderator

Re: Guaranteed CPU shares? [message #37014 is a reply to message #37010]

Tue, 11 August 2009 21:25

laotse
Messages: 35
Registered: December 2008

Member

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?

Report message to a moderator

Re: Guaranteed CPU shares? [message #37031 is a reply to message #36885]

Thu, 13 August 2009 07:37

maratrus
Messages: 1495
Registered: August 2007
Location: Moscow

Senior Member

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?

Report message to a moderator

Re: Guaranteed CPU shares? [message #37065 is a reply to message #37031]

Mon, 17 August 2009 08:26

laotse
Messages: 35
Registered: December 2008

Member

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.

Report message to a moderator

Previous Topic:	direct access to Physical NIC from CT
Next Topic:	WebVZ 2.0 is released

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sun Aug 11 12:36:28 GMT 2024

Total time taken to generate the page: 0.02921 seconds