核心原則：先確認「真兇」是服務器還是網絡/存儲/數據庫
ExtraHop CEO Jesse Rothstein 指出：許多看似服務器問題實為網絡、數據庫、存儲層面引起。Fluke Networks Dan Klimke 建議：延遲問題先判斷首發點——服務器、網絡還是客戶端。
典型拓撲依賴鏈
Web 前端 → 應用服務器 → 數據庫服務器 → 存儲/網絡
故障域劃分：逐層隔離，避免「找錯門」浪費時間。
四大常見性能殺手與定位手段
1. 「繁瑣累贅」應用程序
- 特徵：大量微小幀頻繁交互，TCP 窗口利用率低，RTT 疊加
- 定位：抓包分析（Wireshark/tshark），關注
Frame size、TCP Push、Application turns
- 優化：批量接口、連接池、異步非阻塞、減少序列化開銷
2. 「骯髒」網絡環境
- 特徵：丟包、亂序、碎片、重傳率高，觸發 TCP 慢速路徑重組
- 原理：TCP 快速路徑處理有序全尺寸幀；亂序/碎片強制進入慢速路徑重組，消耗 CPU
- 虛擬化加劇：vSwitch/虛擬網卡調度延遲導致包延遲超時丟棄
- 定位：
netstat -s 看重傳、tcpdump -i any -w 抓包分析亂序/碎片
3. 監控工具「數據洪水」與配置失效
- 痛點：工具默認閾值產生海量告警，運維淹沒在圖表中
- 對策：閱讀手冊、按環境基線調整閾值、分級告警（P1/P2/P3）、告警收斂/靜默
- 推薦：Prometheus+Alertmanager、Zabbix、Datadog、云廠商原生監控
4. 物理資源瓶頸
- CPU：
top/htop/mpstat 看 us/sy/wa/st，高 wa 說明 IO 等待
- 內存：
free -h、vmstat 1 看 si/so（換入/出）、可用內存
- 磁盤：
iostat -x 1 看 %util、await、svctm；df -h 看 inode/空間
- 網卡：
ethtool -S 看錯誤/丟包、sar -n DEV 1 看吞吐
虛擬化環境特有檢查
- CPU Ready 時間（%RDY > 5% 需關注）
- Memory Ballooning/Swapping 發生
- Datastore 延遲（> 30ms 影響性能）
- vMotion/DRS 遷移衝擊
- 工具：vRealize Operations、RVTools、esxtop
容量規劃與負載校準
- 業務高峰（月末結算、大促）預留 30%+ 頭部
- 快照/備份窗口錯峰，避免存儲 IO 風暴
- 硬件匹配軟件需求：Exchange 2010 需 24GB+ RAM，雙路雙核已不足
實時遷移與故障域隔離
- VMware vMotion / Hyper-V Live Migration：熱遷移熱點 VM 釋放資源
- 反親和規則：關鍵服務分散在不同宿主機/機架/可用區
