建立專屬伺服器群組的效能基準
效能基準是針對已知工作負載建立的量度參考，並不是單一的基準測試分數。它描述伺服器在 CPU、記憶體、儲存、網絡、作業系統及應用程式版本均有記錄並保持一致時的運作表現。如果沒有這個參考，團隊可能把變慢視為單一事故，而忽略它其實是整個伺服器群組的效能倒退。
專屬伺服器群組更需要建立基準，因為實體伺服器不會永遠完全相同。不同地區或不同部署日期，可能使用不同 CPU 世代、韌體、記憶體配置、NVMe 型號、RAID 佈局、網絡路由及核心版本。有效的基準可以讓團隊比較同類配置、找出偏移，並決定應否調校、升級、替換或重新分配工作負載。
效能基準應該回答甚麼問題
有效的效能基準需要把工作負載需求與系統容量連繫起來。它應該顯示伺服器可以持續承受的吞吐量、使用者實際感受到的延遲、資源開始飽和的位置、剩餘的容量空間，以及系統在壓力下出現的故障或退化行為。
Dataplugs 的文章 伺服器性能指標：企業成功必備的監控重點 可作為選擇指標的起點，涵蓋正常運行時間、資源使用率、錯誤率、回應時間、並行連線及吞吐量。
- 定義工作負載：每秒請求數、並行工作階段、工作處理量、載荷大小及讀寫比例
- 記錄伺服器身份：CPU 型號、核心數、頻率策略、NUMA 佈局、記憶體類型及容量、儲存型號、RAID、網卡、地區、作業系統、核心及韌體
- 分別量度冷啟動、暖快取、穩態、峰值負載及足以暴露溫度或佇列影響的長時間壓力測試
- 把資源飽和與應用程式限制分開，例如連線池、鎖定、垃圾回收、執行緒池或資料庫等待事件
- 為中位數、p95 及 p99 延遲、錯誤率、CPU、記憶體壓力、磁碟延遲、丟包率及吞吐量設定可接受範圍
讓整個伺服器群組的測試可以重複
只有在測試條件受控時，伺服器群組的基準測試才有比較價值。若要進行有效比較，應盡量使用相同的作業系統映像、核心設定、運行環境版本、容器限制、工作負載產生器、測試資料形狀及網絡路徑。如果硬件類別不同，應建立不同基準，而不是把差異隱藏在單一平均值中。
Dataplugs 的文章 伺服器監控如何保障效能、運作時間與安全性 說明為何應持續觀察 CPU、記憶體、磁碟 I/O、網絡流量及應用程式表現，而不是只在事故發生時才檢查。
- 當 CPU 或 NUMA 位置會影響延遲時，固定基準測試用戶端及伺服器的處理器位置
- 每次測試使用相同的編譯器、運行環境、容器映像、資料庫設定及功能開關
- 有意識地預熱快取；如啟動或快取未命中行為重要，另行執行冷快取測試
- 重複執行每項測試，並報告分佈及信賴範圍，而不是只記錄一次最佳結果
- 保存帶有硬件類別、地區、映像版本、工作負載版本及測試階段標籤的原始時間序列
建立 CPU 及記憶體效能基準
CPU 容量不能只看平均使用率。應記錄 user time、system time、iowait、執行佇列深度、各核心負載差異、頻率調節、溫度降頻及 context switch。比較虛擬化主機時，steal time 可以反映資源爭用；在裸機上如果出現異常 steal 或降頻，則應先調查測量環境。
記憶體基準應把應用程式工作集與 page cache、buffers、回收活動、swap 及核心記憶體分開。對於多插槽系統，亦應觀察 NUMA 位置及跨節點存取。即使整體記憶體使用率不高，單一程序仍可能進行大量回收，或某個 NUMA 節點已經承受壓力。
- 把工作負載吞吐量及 p95/p99 延遲與 CPU 使用率一併觀察；只要延遲仍符合 SLO，高使用率不一定代表問題
- 追蹤記憶體壓力、major page fault、swap 進出、快取回收，以及每個容器或虛擬機的限制
- 把背景掃描、備份、日誌壓縮及監控本身的資源消耗納入基準
- 記錄目標負載下的剩餘空間，並定義何時需要新增伺服器或改用更高配置
- 先按 CPU 型號及頻率策略比較相同工作負載，再判斷某部伺服器是否真的較快
儲存、網絡及應用程式延遲
儲存效能應包括 IOPS、吞吐量、佇列深度、平均延遲、p95/p99 延遲、寫入耐久度及容量增長。隨機及循序存取可能產生完全不同的結果。對資料庫而言，fsync 及 checkpoint 行為可能比循序讀取的標稱數字更重要；對本地佇列而言，尾端延遲及磁碟滿載後的復原方式同樣重要。
如要採用以指標為核心的運作方式，可參考 Dataplugs 的 使用 Prometheus 與 Grafana 進行進階伺服器健康監控，了解如何利用 Node Exporter 提供 CPU、記憶體、磁碟 I/O 及網絡訊號，再按時間作趨勢及關聯分析。
- 按相關路由量度丟包率、往返延遲、jitter、重傳、網卡錯誤、連線速率及持續吞吐量
- 把網絡延遲、TLS handshake、應用程式佇列、資料庫時間及下游服務時間分開
- 使用 p50、p95 及 p99 請求延遲配合錯誤率及吞吐量，避免較快的平均值掩蓋較差的尾端表現
- 在適用時測試儲存飽和、網絡中斷、程序重啟及資料庫故障轉移後的復原行為
- 比較結果前，為每項測量加上工作負載、軟件版本、伺服器類別、地區及測試階段標籤
由效能基準推動容量規劃
只有當效能基準可以推動實際營運決策時，它才真正有用。警示閾值應根據正常範圍及變化速度制定，而不是任意設定單點上限。例如 p99 延遲持續上升並伴隨佇列深度增加，即使 CPU 仍低於 60%，也可能代表儲存或依賴服務出現瓶頸。
對伺服器群組建立按硬件類別分類的效能卡，可以找出配置偏移、失效元件、維護工作及映像或核心更新後的回歸。保留足夠歷史資料，才能分辨逐步增加的容量需求與單次事故，再據此安排升級、重新分配工作負載，或在 SLO 被突破前增加容量。
總結
建立效能基準，可以把專屬伺服器群組由一批獨立機器變成可量度的運作系統。有效基準應在已知測試條件下，結合工作負載吞吐量、p95/p99 延遲、CPU 及記憶體壓力、儲存行為、網絡質素、應用程式錯誤及復原結果，再以 Dataplugs 的 專屬伺服器 配合容量、地區、監控及支援要求作評估。如需了解更多，請聯絡 Dataplugs：sales@dataplugs.com。