資料中心線路飽和 Uplink saturation

原因 ID dc-uplink · 主要負責 基礎設施團隊（網路基礎設施） · 協同基礎設施團隊（伺服器基礎設施）

更新檔發布、log 傳送、備份與遊戲共用同一條線路時，線路會被塞滿。

為什麼 大量傳輸佔用同一條線路 → 於是線路上的排隊與封包遺失增加 → 畫面上 整個伺服器的 ping 上升並出現瞬移

症狀: 輸入延遲, 瞬移
因素: 延遲, 遺失
誰會遇到: 整個伺服器
何時: 固定週期, 人潮湧入時
負責單位: 主要負責 基礎設施團隊（網路基礎設施） · 協同基礎設施團隊（伺服器基礎設施）
基礎設施團隊要做的事: 網路：遊戲流量優先處理（QoS），把大量傳輸的線路分開，設定線路使用率警示。伺服器設備／OS：替備份、log 傳送、部署加上速率限制，並在離峰時段執行。
圖表上: 碰到上限後持平 · 線路使用率、RTT（ping）
查看位置: 把資料中心線路（上行鏈路）介面的使用率（以 SNMP ifHCInOctets、ifHCOutOctets 計算）與輸出丟棄（ifOutDiscards），和備份、部署、log 傳送排程放在同一條時間軸上比對
符合的跡象: 線路使用率貼齊頻寬上限而持平的時間點，整個伺服器的 RTT 與丟棄上升，且該時間點與大量傳輸作業重疊
不符合的跡象: 分鐘級使用率遠低於上限卻有丟棄時是「交換器 microburst」
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）

出處

RFC 4594: Configuration Guidelines for DiffServ Service Classes IETF
把遊戲這類即時互動流量與備份這類大量傳輸，分成不同的服務等級處理
RFC 7567: IETF Recommendations Regarding Active Queue Management IETF
進入設備的量超過送出速度時佇列就會堆積，過多的佇列是延遲的主要原因
RFC 2863: The Interfaces Group MIB IETF
ifHCInOctets、ifHCOutOctets：介面收到與送出的位元組數（64 位元），ifOutDiscards：無法送出而被丟棄的封包數