[cisco-voip] CPU Reservations

[Wes Sisk (wsisk)]

Adam,

Yes, the reservation appears steep and outside monitors appear ripe for harvesting underutilized resources.


And 3 things come to mind:

* ccm.bin at its core is a distributed real time state machine. Delays have serious impacts. Feature are invoked across nodes. See the long history around CCM clustering over the WAN requirements for more background.
* mtp/moh/cfb are all essentially real time for audio.
* some processes are less predictable in their consumption of resources. “Resource Starvation” has many symptoms across features that are difficult to diagnose. This consumes more of your time as implementers, admins, and monitors. And it significantly degrades customer experience of the product and people servicing the product. There is an element of resource allocation that is akin to road infrastructure planning - it may appear idle many times and it can still be under provisioned during peak demand.

Consider for example
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtu18692

This under provision/over subscription negatively impacted several deployments.

In my experience VOIP has been a bit of a “canary in the coal mine” for IP applications. I see many situations where users are willing to re-send an email. Meanwhile the first call that does not go through, gets dropped, or suffers poor audio is grounds for immediate escalation.

Maybe some things to consider.

-Wes

On Jul 8, 2019, at 11:57 AM, Pawlowski, Adam <ajp26 at buffalo.edu<mailto:ajp26 at buffalo.edu>> wrote:

Hi all,

It’s been a bit since I’ve asked this question, if I have here before.

Do we all run our UC appliances in VMWare with the full CPU MHz and core reservations prescribed by Cisco, in production? Or, if you have information on hand regarding the actual resource usage, have any of you taken on resizing the VM reservations?

The various documents are very much so clear that oversubscription isn’t supported, but, it also talks about vCPU to cores which I’m told doesn’t really play out in VMWare as it’s a MHz reservation that can be scheduled in to available hardware.

There are various statements peppered in about running your own VM environment with best practices – but also the 1:1 pcore:vcore comments.

Is anyone turning these knobs? Has anyone stepped over that pcore:vcore line when it appears there are enough resources?

I’m looking for thoughts or unforeseen consequences that we can use to back somewhat of the case as to why we need to continue to fund hardware at scale which is largely idle.

Adam


_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190708/ab6d1a69/attachment.htm>