伺服器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（在 VMWare ESXi 5.5 客戶機上執行，帶有新更新的工具和 VMXNET3 適配器。）CPU 的使用率穩定在 5-15% 左右，網路流量極小。我在哪裡可以解決此問題？此類問題是否有任何常見原因？我假設由於伺服器上存在問題，我可以排除外部網路端的問題嗎？
終於想通了！TLDR：禁用主機上的電源管理。
儘管 CPU 使用率很低，但我們仍然認為這與 CPU 負載有關。因此，我們正在嘗試降低 CPU 的負載，預計呼叫中的死點問題會變得更糟。相反，它完全消失了。因此，在多次查看 vCenter 中的 CPU 使用情況統計資訊後，我終於查看了該圖上的另一條線。
這對很多人來說可能不是新聞，但我發現CPU 就緒時間是 VM 準備好使用 CPU 的時間量，但主機無法分配物理資源。我發現的大多數消息來源都說低於 5% 的任何東西都不是問題，但它確實似乎對我們的語音流產生了影響。我們每分鐘都在看到剪裁，而且圖表還顯示每分鐘的準備時間都有一個高峰。
所以我想知道為什麼這會在高 CPU 負載時消失，並認為它一定是某種電源管理。當主機看到使用率增加時，它會使 CPU 資源始終可用於 VM。所以我在主機的 BIOS 中禁用了電源管理，等等：
接近圖表末尾的就緒時間略有增加，對應於遷移回該主機的其他六台虛擬機。
呼叫跟踪現在顯示的抖動量可以忽略不計，並且切口已從呼叫中消失。進一步的研究表明，對於延遲敏感和 CPU 非密集型工作負載來說，這是一個比較常見的問題。電源管理看到非常低的 CPU 使用率並假設它可以限制處理器，即使它不應該！
