原作來源:https://queue.acm.org/detail.cfm?id=2413037

作者:Brendan Gregg, Joyent(作者現服務於 Netflix )

現代的系統由於牽涉到多個 component 間的交互作用,使得系統效能分析越來越難鑑識出 bottleneck 的來源。 以往的 methodolody 有的缺乏科學化分析,有的則是曠日費時。所以作者提出一個可以快速分析的方法 USE Method,希望可以在效能分析的早期,快速的定位出系統性 bottleneck 的方向。之後再搭配其他的 methodology 找出真的問題。

USE 表示 utilization、saturation 及 error。在效能分析的早期,跑完 problem-statement method 之後, 首先,我們可以大略描繪出整個系統的 function block diagram ,列出資源列表。並且針對每個 resource 檢查它們的 utilization、saturation 與 error 的情形是否有異常。

舉例來說,我們可大概列出如下的 resource list (擷取自原文)

  • CPUs—Sockets, cores, hardware threads (virtual CPUs).
  • Main memory—DRAM.
  • Network interfaces—Ethernet ports.
  • Storage devices—Disks.
  • Controllers—Storage, network.
  • Interconnects—CPU, memory, I/O.

針對每個 resource 尋找跟 U/S/E 相關的量化指標,如 CPU 使用率,記憶體使用量可視為 saturation 指標、 network error number 等。有些較難分析的部分也許必須自行客製化相關的 profiling tool 與指標。

最後就是針對這些量測出來的數據分析了。作者對於指標的解讀提出了一些建議,

  • utilization:100% 的使用率通常是瓶頸的徵兆。高使用率(例:超過 60%)有可能開始造成其他問題的發生。
    • 量測通常是取一對時間平均,所以測量到高使用率,比如說總計 60% 使用率,可能隱藏短時間達到 100% 使用率。
    • 再來,有些系統資源操作中通常無法被中斷,如硬碟,一旦使用率在60%以上,在 queue 等待的延遲可能會越來越頻繁越顯著。
  • saturation: 任何程度的 saturation 都可能是問題(非零)。可以以一個等待 queue 的長度或是花在等待 queue 的時間來測量。
  • error:非零的 error count 是值得調查的,特別是如果他們在效能很差時還持續增加。
    • error count 先檢查,因為他們通常比起使用率與飽和度更容易且更快解譯。

USE method 辨認出可能是系統瓶頸的問題。不幸的系統可能出現超過一個 performance issue,所以第一個你找到的可能是 其中一個但不是真正的問題。你可以使用更進一步的 methodology 來調查每一個發現的結果。


Viller Hsiao

All about C/C++/Python, Embedded Linux/RTOS, and Web programming