服务器端RTP抖动的原因
mik*_*n32 5 virtual-machines jitter asterisk voip rtp
调查一些通话质量问题（通话中 0.5 – 1 秒的死点） 我在同一个 PBX 上的两个分机之间捕获了一个电话呼叫的数据包。因为我是从 PBX 捕获的，所以我很惊讶地看到 Wireshark 报告了一个巨大的抖动峰值，它与呼叫中的死点同步：
我的理解是抖动是由传输中的数据包丢失和/或延迟引起的，并且离开 PBX 的 RTP 流应该相对原始。但是这个峰值出现在所有四个 RTP 流中（办公室 1 到 PBX、办公室 2 到 PBX、PBX 到办公室 1、PBX 到办公室 2）所以看起来数据包在离开服务器时已经处于不良状态。
PBX 是 Scientific Linux (RHEL) 6.9 上的 Asterisk 13（在具有新更新工具和 VMXNET3 适配器的 VMWare ESXi 5.5 客户机上运行）。CPU 使用率稳定在 5-15% 左右，并且网络流量很小。在哪里可以查找解决此问题的方法？此类问题是否有任何常见原因？我假设既然问题出在服务器上，我可以排除外部网络方面的问题吗？
终于弄清楚了！TLDR：禁用主机上的电源管理。
尽管 CPU 使用率较低，但我们仍然认为这与 CPU 负载有关。因此，我们正在尝试降低 CPU 负载，预计调用中的死点问题会变得更糟。相反，它完全消失了。因此，在多次查看 vCenter 中的 CPU 使用统计数据后，我最终查看了该图表上的另一条线。
这对很多人来说可能不是什么新闻，但我发现CPU 就绪时间是指虚拟机准备好使用 CPU，但主机无法分配物理资源的时间。我发现的大多数消息来源都说低于 5% 的值都不是问题，但它似乎确实对我们的语音流产生了影响。我们每分钟都会看到切口，图表还显示每分钟准备时间都会激增。
所以我想知道为什么在高 CPU 负载期间这个问题会消失，并认为这一定是某种电源管理。当主机发现使用率增加时，它会持续向虚拟机提供 CPU 资源。所以我在主机的 BIOS 中禁用了电源管理，等等：
在图表末尾附近，准备时间略有增加，对应于六个其他虚拟机迁移回该主机。
通话痕迹现在显示的抖动量可以忽略不计，而且通话中的断线也消失了。进一步的研究表明，对于延迟敏感且 CPU 非密集型的工作负载来说，这是一个比较常见的问题。电源管理发现 CPU 使用率非常低，并假设它可以限制处理器，即使它不应该！