服務性能監控：USE方法（The USE Method）

USE 方法是一種能分析任何系統性能的方法論。 我們可以根據能幫助系統分析的結構化清單，來迅速的定位資源的瓶頸和錯誤所在。 它通常會先以列出問題為開始，然后再尋找適合的指標，而不是給你制定一些固定的指標， 然后讓你按部就班的執行下去。

本頁左側下方，是我列出的，根據不同的操作系統（Linux、 Solaris 等） 衍生的 USE 方法列表。（譯者注：可以參考原文鏈接）

我列出了為不同的操作系統而衍生的 USE 方法列表供大家參考， 你們可以根據你的環境來為你的站點服務，選擇適合的附加監控指標。

通過這個工具，可以很方便的篩選出適合不同的系統的建議 metrics：USE Method: Rosetta Stone of Performance Checklists

Intro（Introduction）

如果你遇到一個很嚴重的性能問題升級的時候，并且你不能確定它是否由服務導致的， 這時候你該怎么辦？

我們都說萬事開頭難。所以我開發出了 USE 方法，來幫助大家，如何去快速的解決常見的性能問題，而同時又不容易忽略重要的地方。

USE 方法在設計之初就定位了簡潔、明了、完整、快速的特性， 就好像一本航天手冊的緊急事項列表那樣。 （譯者注：航天手冊，介紹包括不限于飛機的各種特性、指標、性能等， 用于幫助飛行學員學習駕駛飛機，或者是幫助那些希望提高他們的飛行潛能和航空知識的人了解的更全面）。

USE 方法已經在不同的企業、課堂（作為學習工具）以及最近的云計算等場景中，被成功應用了無數次。

USE 方法基于 3+1 模型（三種指標類型+一種策略），來切入一個復雜的系統。我發現它僅僅發揮了 5% 的力量，就解決了大概 80% 的服務器問題，并且正如我將證明的，它除了服務器以外，也同樣適應于各種系統。

它應當被理解為一種工具，一種很大的方法工具箱里面的工具。不過，它目前仍然還有很多問題類型以待解決，還需要點其他方法和更多的時間。

Summary

USE 方法可以概括為：檢查所有的資源的利用率，飽和度，和錯誤信息。

我們期望大家能盡早使用 USE 方法去做性能檢查，或者是用它確定系統的瓶頸。

名詞定義：

• 資源： 服務器功能性的物理組成硬件（CPU， 硬盤, 總線）
• 利用率： 資源執行某工作的平均時間
• 飽和：衡量資源超載工作的程度，往往會被塞入隊列
• 錯誤： 錯誤事件的數量

分析軟件資源，或者是軟件的強制性限制（資源控制）也是很有用的，同時要關注哪些指標是處于正常的可接受范圍之內的。這些指標通常用以下術語表示：

• 利用率： 以一個時間段內的百分比來表示，例如：一個硬盤以 90% 的利用率運行
• 飽和度： 一個隊列的長度，例如：CPUs 平均的運行時隊列長度是4
• 錯誤（數）： 可度量的數量，例如：這個網絡接口有 50 次（超時？）

我們應該要調查那些錯誤，因為它們會降低系統的性能，并且當故障模型處于可回復模式的時候，它可能不會立刻被發現。

這包括了那些失敗和重試等操作，以及那些來自無效設備池的失效設備。

低利用率是否意味著未飽和？

即使在很長一段時間內利用率很低，一個爆發增長的高利用率，也會導致飽和 and 性能問題，這點要理解起來可能有違三觀！

我舉個例子，有一位客戶遇到的問題，即使他們的監控工具顯示 CPU 使用率從來沒有超出過 80% ，但是 CPU 飽和度依然有問題（延遲）監控工具報告了 5 分鐘的平均值，而其中，CPU利用率曾在數秒內高達 100% 。

資源列表

下面來看如何開始使用。

準備工作時， 你需要一個資源列表來按步就班的去做。 下面是一個服務器的通用列表：

• CPUs： sockets, cores, hardware threads (virtual CPUs)
• 內存： 容量
• 網絡接口
• 存儲設備： I/O, 容量
• 控制器： 存儲, 網卡
• 通道： CPUs, memory, I/O

有些組件分兩種類型的資源：存儲設備是服務請求資源（I / O） 以及容量資源（population）， 兩種類型都可能成為系統瓶頸。 請求資源可以定義為隊列系統，可以將請求先存入排隊然后再消化請求。

有些物理組件已被省略，例如硬件緩存（例如，MMU TLB / TSB，CPU）。

USE 方法對于在高利用率或高飽和度下，遭受性能退化、導致瓶頸的資源最有效，在高利用率下緩存可以提高性能。

在使用 USE 方法排除系統的瓶頸問題之后 ，你可以檢查緩存利用率和其他的性能屬性。

如果你不確認要不要監控某一個資源時，不要猶豫，監控它，然后你就能看到那些指標工作的有多么的棒。

功能模塊示意圖

另外一種迭代資源的方法，是找到或者繪制一張系統的功能模塊示意圖。

這些顯示了模塊關系的圖，在你查找數據流的瓶頸的時候是非常有用的，這里有一張Sun Fire V480 Guide(page 82)的例圖：

我喜歡這些圖表，盡管制作出它很難。 不過，由硬件工程師來畫這張圖是最適合的-他們最善于做這類事。如果不信的話你可以自己試試。

在確定各種總線的利用率的同時，為每個總線的功能圖表，注釋好它的最大帶寬。這樣我們就能在進行單次測量之前，得到能將系統瓶頸識別出來的圖表。

Interconnects

CPU，內存和I / O interconnects 往往被忽略。 幸運的是，它們并不會頻繁地成為系統的瓶頸。 不幸的是，如果它們真的頻繁的成為瓶頸，我們能做的很少（也許你可以升級主板，或減少 load：例如，"zero copy"項目減輕內存總線 load）。

使用 USE 方法，至少你會意識到你沒有考慮過的內容：interconnect 性能。 有關使用 USE 方法確定的互連問題的示例，請參閱分析 Analyzing the HyperTransport。

Metrics

給定資源列表，識別指標類型：利用率，飽和度和錯誤指標。這里有幾個示例?？聪旅娴?table，思考下每個資源和指標類型，metric 列是一些通用的 Unix/Linux 的術語提示（你可以描述的更具體些）：

---

resource type metric CPU utilization CPU utilization (either per-CPU or a system-wide average) CPU saturation run-queue length or scheduler latency(aka Memory capacity utilization available free memory (system-wide) Memory capacity saturation anonymous paging or thread swapping (maybe "page scanning" too) Network interface utilization RX/TX throughput / max bandwidth Storage device I/O utilization device busy percent Storage device I/O saturation wait queue length Storage device I/O errors device errors ("soft", "hard", ...)

---

這些指標是每段間隔或者計數的平均值，作為你的自定義清單，要包括使用的監控軟件，以及要查看的統計信息。如果是不可用的指標，可以打個問號。最后，你會完成一個完事的、簡單、易讀的 metrics 清單.

Harder Metrics

再來看幾個硬件指標的組合

---

resource type metric CPU errors eg, correctable CPU cache ECC events or faulted CPUs (if the OS+HW supports that) Memory capacity errors Network saturation Storage controller utilization CPU interconnect utilization Memory interconnect saturation I/O interconnect utilization

---

這些依賴于操作系統的指標一般會更難測量些， 而我通常要用自己寫的軟件去收集這些指標。

重復所有的組合，并附上獲取每個指標的說明，你會完成一個大概有30項指標的列表，其中有些是不能被測量的，還有些是難以測量的。

幸運的是，最常見的問題往往是簡單的（例如，CPU 飽和度，內存容量飽和度，網絡接口利用率，磁盤利用率），這類問題往往第一時間就能被檢查出來。

本文的頂部，pic-1中的 example checklists 可作為參考。

In Practice

讀取系統的所有組合指標，是非常耗時的，特別是當你開始使用總線和 interconnect 指標的情況下。

現在我們可以稍微解放下了，USE 方法可以讓你了解你沒有檢查的部分,你可以只有關注其中幾項的時間例如：CPUs, 內存容量, 存儲容易, 存儲設備 I/O, 網絡接口等。通過 USE 方法，那些以前未知的未知指標現在變成了已知的未知指標（我理解為，以前我們不知道有哪些指標會有什么樣的數據，現在起碼能知道我們應該要關注哪些指標）。

如果將來定位一個性能問題的根本原因，對你的公司至關重要的時候，你至少已經有一個明確的、經過驗證的列表，來輔助你進行更徹底的分析，請完成適合你自己的 USE 方法，有備無患。

希望隨著時間的推移，易于檢查的指標能得以增長，因為被添加到系統的 metrics 越多，會使 USE 方法將更容易（發揮它的力量）。 性能監視軟件也可以幫上忙，添加 USE 方法向導to do the work for you（do what work? ）。

Software Resources

有些軟件資源可以用類似的方式去分析。 這通常適用于軟件的較小組件，而不是整個應用程序。 例如：

• 互斥鎖(mutex locks)：利用率可以定義為鎖等待耗時；飽和率定義為等待這把鎖的線程個數。
• 線程池：利用率可以定義為線程工作的時長；飽和率是等待線程池分配的請求數量。
• 進程/線程 容量：系統是有進程或線程的上限的，它的實際使用情況被定義為利用率；等待數量定義為飽和度；錯誤即是（資源）分配失敗的情況（比如無法 fork）。 （譯注：fork 是一個現有進程，通過調用 fork 函數創建一個新進程的過程)
• 文件描述符容量(file descriptor capacity)：和上述類似，但是把資源替換成文件描述符。

如果這幾個指標很管用就一直用，要不然軟件問題會被遺留給其他方法了（例如，延遲，后文會提到其他方法：other methodologies ）。

Suggested Interpretations

USE 方法幫助你定位要使用哪些指標。 在學習了如何從操作系統中讀取到這些指標后，你的下一步工作就是詮釋它們的值。對于有的人來說， 這些詮釋可能是很清晰的（因為他們可能很早就學習過，或者是做過筆記）。而其他并不那么明了的人，可能取決于系統負載的要求或期望 。

下面是一些解釋指標類型的通用建議：

• Utilization： 利用率通常象征瓶頸（檢查飽和度可以進一步確認）。高利用率可能開始導致若干問題：
• 對利用率進行長期觀察時（幾秒或幾分鐘），通常來說 70% 的利用率會掩蓋掉瞬時的 100% 利用率。
• 某些系統資源，比如硬盤，就算是高優先級請求來了，也不會在操作進行中被中斷。當他們的利用率到 70% 時候，隊列系統中的等待已經非常頻繁和明顯。而 CPU 則不一樣，它能在大部分情況下被中斷。
• Saturation：任何非 0 的飽和度都可能是問題。它們通常是隊列中排隊的時間或排隊的長度。
• Errors：只要有一條錯誤，就值得去檢查，特別是當錯誤持續發生從而導致性能降低時候。

要說明負面情況很容易：利用率低，不飽和，沒有錯誤。 這比聽起來更有用 - 縮小調查范圍可以快速定位問題區域。

Cloud Computing

在云計算環境中，軟件資源控制可能是為了限制 使用共享計算服務的 tenants 的流量。在 Joyent 公司，我們主要使用操作系統虛擬化（SmartOS），它強加了內存限制， CPU 限制和存儲I / O限制。 所有這些資源限制，都可以使用USE Method進行檢查，類似于檢查物理資源。

例如，在我們的環境中，"內存容量利用率"可以是 tenants 的內存使用率 vs 它的內存上限 。即使傳統的 Unix 頁面掃描程序可能處于空閑狀態，也可以通過匿名頁面活動看到"內存容量飽和度"。

Strategy

下面是用流程圖 的方式畫了 USE 方法的示意圖。 請注意，錯誤檢查優先于利用率和飽和度檢查（因為通常錯誤更快的表現出來，并更容易解釋）。

USE 方法定位到的問題，可能是系統瓶頸。 不幸的是，系統可能會遇到多個性能問題，因此您發現的第一個可能的問題最終卻不是個問題。 發現的每個問題都可以用方法持續的挖掘，然后繼續使用 USE 方法對更多資源進行反復排查。

進一步分析的策略包括工作量特征和 drill-down 分析。 完成這些后，你應該有依據據能判斷，糾正措施是要調整應用的負載或調整資源本身。

Apollo

（譯者注：Apollo 這一段我們可以不太關注，它主要是講 USE 方法，與阿波羅登月計劃相關的系統設計的一些淵源）

我之前有提到過，USE 方法可以被應用到除服務器之外。為了找到一個有趣的例子， 我想到了一個我沒有完全不了解的系統，并且不知道從哪里開始：阿波羅月球模塊指導系統。 USE 方法提供了一個簡單的流程來嘗試第一步是尋找一個資源列表，或者更理想的話，找到一個功能模塊圖表。我在 【Lunar Module - LM10 Through LM14 Familiarization Manual】中發現了以下內容：

這些組件中的一部分可能未表現出利用率或飽和度特性。在迭代后， 就可以重新繪制只包含相關組件的圖表（還可以包括："可擦除存儲"部分的內存，"核心區域"和 "vac區域 "寄存器）。

我將從阿波羅主腦（AGC）本身開始。 對于每個指標，我瀏覽了各種 LM 文檔，看看哪些是合理的（有意義的）：

• AGC utilization： This could be defined as the number of CPU cycles doing jobs (not the "DUMMY JOB") divided by the clock rate (2.048 MHz). This metric appears to have been well understood at the time.
• AGC saturation： This could be defined as the number of jobs in the "core set area", which are seven sets of registers to store program state. These allow a job to be suspended (by the "EXECUTIVE" program - what we\'d call a "kernel" these days) if an interrupt for a higher priority job arrives. Once exhausted, this moves from a saturation state to an error state, and the AGC reports a 1202 "EXECUTIVE OVERFLOW-NO CORE SETS" alarm.
• AGC errors： Many alarms are defined. Apart from 1202, there is also a 1203 alarm "WAITLIST OVERFLOW-TOO MANY TASKS", which is a performance issue of a different type： too many timed tasks are being processed before returning to normal job scheduling. As with 1202, it could be useful to define a saturation metric that was the length of the WAITLIST, so that saturation can be measured before the overflow and error occurs.

其中的一些細節，可能對于太空愛好者來說是非常熟悉的：在阿波羅 11 號降落的時候發生的著名的 1201（"NO VAC AREAS"）和 1202 警報。（"VAC"是向量加速器的縮寫， 用于處理 vector quantities 作業的額外存儲； 我覺得 wikipadia 上將 "向量"描述為"空"可能是錯誤的）。

鑒于阿波羅 11 號的 1201 警報，可以繼續使用其他方法分析，如工作負載表征。 工作負載很多可以在功能圖中看到，大多數工作負載是通過中斷來生效的。 包括用于跟蹤命令模塊的會合雷達，即使 LM 正在下降，該模塊也仍然在執行中斷 AGC（阿波羅主腦）的任務。 這是發現非必要工作的一個例子（或低優先級的工作; 雷達的一些更新可能是可取的，因此 LM AGC可以立即計算出中止路徑）。

作為一個更深的例子，我將把會合雷達當作資源去檢查. 錯誤最容易識別。 有三種信號類型： "DATA NO GOOD", "NO TRACK", and "SHAFT- AND TRUNNION-AXIS ERROR"。

在有某一小段時間里，我不知道能從哪里開始使用這個方法, 去尋找和研究具體的指標。

Other Methodologies

雖然 USE 方法可能會發現 80％ 的服務器問題，但基于延遲的方法（例如Method R）可以找到所有的問題。 不過，如果你不熟悉軟件內部結構，Method R 就有可能需要花費更多時間。 它們可能更適合已經熟悉它的數據庫管理員或應用程序開發人員。

而 USE 方法的職責和專長包括操作系統（OS）和硬件，它更適合初級或高級系統管理員，當需要快速檢查系統健康時，也可以由其他人員使用。

Tools Method

以下介紹一個基于工具的方法流程（我稱它作"工具方法"），與 USE 方法作比較：

1. 列出可用的性能工具（可以選擇性安裝或購買其他的）。
2. 列出每個工具提供的有用的指標
3. 列出每個工具可能的解釋規則

按照這個方法做完后，將得到一個符合標準的清單，它告訴我們要運行的工具，要關注的指標以及如何解釋它們。 雖然這相當有效，但有一個問題，它完全依賴于可用（或已知的）的，可以提供系統的不完整視圖的工具。 用戶也不知道他們得到的是一張不完整的視圖 - 所以問題將仍然存在。

而如果使用 USE 方法，不同的是， USE 方法將通過迭代系統資源的方式，來創建一個完整的待確認問題列表，然后搜索工具來回答這些問題。這樣構建了一張更完整的視圖，未知的部分被記錄下來，它們的存在被感知（這一句我理解成前文中提到的：未知 的未知變為已知的未知）。 基于 USE ，同樣可以開發一個清單類似于工具方法(Tool-Method)，顯示要運行的工具（可用的位置），要關注的指標以及如何解釋它。

另一個問題是，工具方法在遍歷大量的工具時，將會使尋找瓶頸的任務性能得到分散。而 USE 方法提供了一種策略，即使是超多的可用工具和指標，也能有效地查找瓶頸和錯誤。

Conclusion

USE 方法是一個簡單的，能執行完整的系統健康檢查的策略，它可以識別常見的系統瓶頸和錯誤。它可以在調查的早期部署并快速定位問題范圍，如果需要的話，還可以進一步通過其他方法進行更詳細的研究。

我在這個篇幅上，解釋了 USE 方法并且提供了通用的指標案例，請參閱左側導航面板中對應操作系統的示例清單， 其建議了應用 USE 方法的工具和指標。另請參閱基于線程的補充方法，TSA Method。

Acknowledgments

• 感謝 Cary Millsap and Jeff Holt (2003) 在"優化Oracle性能"一文中提到的 Method R 方法 (以及其他方法), 使我有了靈感，我應該要把這個方法論寫出來。
• 感謝 Sun Microsystems 的組織，包括 PAE 和 ISV， 他們將 USE 方法（那時還沒命名）應用于他們的存儲設備系列，繪制了標注指標和總線速度的 ASCII 功能塊圖表 - 這些都比您想象的要困難（我們應該早些時候詢問硬件團隊的幫助）。
• 感謝我的學生們，多年前我授予他們這個方法論，謝謝他們提供給我的使用反饋。
• 感謝 Virtual AGC 項目組（The Virtual AGC project），讀他們的站點 ibiblio.org 上的文檔庫，就象是一種娛樂. 尤其是 LMA790-2 "Lunar Module LM-10 Through LM-14 Vehicle Familiarization Manual" ( 48 頁有功能模塊圖表), 以及 "阿波羅指導和月球導航模塊入門學習指南", 都很好的解釋了執行程序和它的流程圖 (These docs are 109 and 9 Mbytes in size.)
• 感謝 Deirdré Straughan 編輯和提供反饋，這提高了我的認知。
• 文章頂部的圖片，是來自于波音 707 手冊，1969 出版。它不是完整的，點擊查看完整的版本（譯注：為方便閱讀，就是下面這張：）

Updates

USE Method updates：（略）

• It was published in ACMQ as Thinking Methodically about Performance (2012).
• It was also published in Communications of the ACM as Thinking Methodically about Performance (2013).
• I presented it in the FISL13 talk The USE Method (2012).
• I spoke about it at Oaktable World 2012： video, PDF.
• I included it in the USENIX LISA `12 talk Performance Analysis Methodology.
• It is covered in my book on Systems Performance, published by Prentice Hall (2013).

More updates (Apr 2014)：

• LuceraHQ are implementing USE Method metrics on SmartOS for performance monitoring of their high performance financial cloud.
• LuceraHQ 正在 SmartOS 上，為他們高性能金融云的性能監測，實施 USE 方法指標
• I spoke about the USE Method for OS X at MacIT 2014 (slides)。

原文轉自：https://blog.alswl.com/2017/11/use-method/