Home 技術文章 大規模伺服器優化:消除數據包丟失並提高容量
Applications

大規模伺服器優化:消除數據包丟失並提高容量

About The Author

Outline

為客戶及其受眾的利益提昇我們技術的性能是Verizon Media (現為Edgio)的持續行動方針。 例如,在過去的兩年中,我們的性能和內核工程師幾乎消除了所有數據包丟棄(移除的數據包超過98%),將邊緣伺服器上的性能執行狀況檢查提高了50%,並將伺服器容量提高了40%。

我們還將上述功能與網路自動化和有機網路擴展相結合(目前超過250 Tbps),以改善用戶體驗。 當我們為數百萬個遊戲控制臺提供軟體更新,為重大體育賽事提供實時影片流,以及多CDN負載平衡器將負載移至我們的網路時,仔細調整我們的性能在我們支援快速變化,有時無法預測的網路激增方面發揮了重要作用。

大規模維護質量涉及優化Edgio Media Platform技術堆棧的每個部分的性能:從下層,CPU和NIC到操作系統和應用程式。 最終,我們的目標始終是一樣的:卓越的績效。 為了達到這個目標,我們會執行資料導向的分析,並依據可測量的效能變更來驗證我們的決策。

CPU高速暫存優化

我們在全球執行20,000臺伺服器,主要是Broadwell和Haswell晶片組,通常具有32到40個內核。 僅在過去三年中,我們就增加了12,000臺服務器。 但是,大多數伺服器未經過優化,無法開箱即用地進行擴展。 僅僅添加更多伺服器並不能提高營運效率,而且還會帶來更多挑戰。 有效的擴展需要仔細優化現有組件。 能夠優化一臺伺服器,使其能夠處理比預設配置更多兩三倍(或更多)的請求,這對網路的整體性能有很大的影響。

從早期偵聽到家庭偵聽的切換

現代CPU採用snoop協議來保證本地CPU高速暫存與記憶體一致。 這樣,超速緩存就可以偵聽對任何CPU上變量的修改,並相應地更新這些變量的版本。 毫不奇怪,所使用的特定技術會顯著影響記憶體性能。

默認情況下,我們的硬件供應商使用一種稱爲Early Snoop的協議。 由於所有內核都可以同時發出高速暫存一致請求並發送廣播,因此解決高速暫存一致性的延遲更低。 我們發現,在高峰負載情況下,我們的系統會同時產生大量磁碟和NIC活動。 這些活動會導致高強度的snoop廣播,從而導致通信瓶頸。 這會導致IO設備變慢,並最終導致處理完全停止。

通過切換到主監聽模式(一種合併監聽請求的方法),我們看到廣播流量顯著減少。 處理器的Quick Path Interconnect (QPI)在同時執行大量磁碟和網路IO操作期間不再需要資源;此外,我們在早期Snoop中看到的數據包丟棄數量顯著減少。

更改snoop協議只取決於更改BIOS設定。 但是,在不中斷客戶的情況下重新啟動20,000臺伺服器需要自動化。 我們可以使這種大規模部署更改在生產中發揮作用,部分原因是我們基於StackStorm的IT自動化平臺Cryfish。

意外故障轉移事件

在測試切換到Home Snoop的過程中,發生了故障轉移:我們最大的媒體客戶之一(部署多CDN)遇到了另一家供應商的問題,並將其大部分流量轉移到了我們的CDN。 這提供了測試大規模Home Snoop改進的機會,這些改進非常有影響力。

上圖顯示了更改的效果。 仍在使用早期Snoop的該組的數據包跌落次數增加了13.75倍(每臺伺服器每天丟棄55K數據包),而改用Home Snoop的該組僅增加了4.23倍(每臺機器每天丟棄27K數據包)。 Home Snoop在故障轉移事件期間立即證明瞭其價值。

網路接口優化和驅動程式調整

另一組重要的性能調整涉及網路接口和驅動程式。 在這裡,我們著重於減少通常發生在突發流量時的數據包丟棄。 在大型事件中,入站流量非常大,網卡無法跟上,我們看到數據包丟失的速度比預期的要快。 在我們深入探討原因時,我們發現NIC本身的幾個參數需要調整,包括隊列數量,隊列大小和中斷調度。 為了優化特定工作負載和硬體配置的這些規範,我們集中精力調整接收端調整(RSS),方法是延長入站隊列的時間,減少其總數,並在NUMA節點之間平衡中斷。

上圖顯示了我們在北美進行的測試,其中每個POP被分為一個控制(即未調諧)組和一個測試(即已調諧)組。 這裡,我們顯示了一週內每天的滴注次數。 調整後,我們的測試組發現的數據包丟棄量比控制組減少了大約95%,允許處理的請求數量顯著增加。 這也意味著在電湧時,手動管理網路健康狀況所需的操作更少,使我們的工程師可以專注於其他領域。

CPU調度調整

NIC和驅動程式級別調整集中於提高我們可以提供的總容量,而CPU調度調整則集中於增強我們交付內容的一致性。

如果沒有這些調整,入站和出站消息就必須爭奪資源。 當我們開始調查根本原因時,我們發現資源爭用是內核如何安排這些消息的處理造成的。 這意味著負載不會在尖峰流量期間遷移,直到相關CPU飽和之後。 要解決此問題,我們將Web伺服器進程的CPU關聯性設定為排除專用於處理傳入網路流量的CPU。

上圖顯示了3月21日至22日在整個CDN中全局啟用CPU調度調整的影響。 我們根據性能執行狀況檢查度量的95百分位值和中間值來評估影響,這是一個顯示伺服器相對響應時間的複合度量。 正如預期的那樣,低流量下限並未顯著降低;但是,峰值表明傳入和傳出流量之間的爭用顯著減少。 這意味著在異常值和中位數方面都有了重大改進,尤其是在峰值負載期間。 我們現在可以更好地處理流量激增並消除與高異常行爲相關的問題,例如視頻流中的重新緩衝或服務器對所有用戶的整體響應。

內核性能更新

優化技術堆棧的上層與調整下層元素同樣重要。 在最近升級我們的操作系統的過程中,我們還升級了Linux內核,以充分利用Linux內核社群的上游工程工作。 新內核的開發時間比以前的版本要長約四年,包括改進了記憶體管理系統,減少了阻止頁面分配,並在使用epoll API和套接字分段時提高了負載分配和性能。

在上圖中,您可以看到從11月底到1月初升級過程的影響,因為第99個百分位的性能執行狀況檢查下降。 基礎內核改進導致在我們所有Web伺服器請求處理器之間的負載分布更加均勻。 這導致這些異常值大幅下降,使我們對所有客戶的請求更加可靠。

性能調整具有顯著的影響

在過去的98年中,性能和內核工程部署的影響深遠的系統調整幾乎消除了所有數據包丟失(刪除的數據包超過了50%),並將邊緣伺服器上的性能執行狀況檢查減半。 我們的伺服器容量增加了10–40 %(具體數量因客戶配置和活動而異),使我們能夠更快地提供更多流量。 異常值行為顯著改善,從而實現了更一致的體驗,並且我們也看到了介質的良好改進,尤其是在峰值負載期間。 總而言之,對整個技術堆棧的性能調整使我們能夠更好地處理任何意外的流量高峰(無論是來自高度預期的遊戲控制臺更新還是熱門的流媒體直播影片),並為所有用戶提供更一致的性能。