[[431322]]

性能問題往往是復雜和神秘的，可能根本沒有或很少提供關于其起源的線索。在沒有起點或者沒有提供方法的情況下，性能問題通常是隨機分析的: 猜測問題可能在哪里，然后改變事情，直到問題消失。如果我們猜得沒錯的話，雖然這可能會有結果 ，但它也可能會耗費大量時間或者具有破壞性，并可能最終忽視某些問題。

關于系統性能的那些問題

典型系統中組件的數量龐大，系統的性能分析是復雜的。一個環境可以由數據庫、 Web 服務器、負載均衡器和定制應用程序等組成，所有這些都運行在操作系統上(裸機或虛擬機)。這還只是軟件而已，硬件和固件，包括外部的存儲系統和網絡基礎設施，向環境中添加了更多的組件，其中任何組件都是潛在的問題根源。每一個組件都可能需要自己的專業領域，而且公司往往沒有了解其環境中所有組件的員工。

性能問題還可能來自組件之間的復雜交互，這些交互可以很好地獨立工作，解決這類問題可能需要多個領域的專家共同努力。

另一個復雜的因素是，性能的好壞可能是主觀的: 一個用戶不能接受的延遲對另一個用戶可能是可以接受的。如果沒有辦法清楚地確定問題，不僅很難知道問題是否存在，而且很難知道問題何時得到解決。衡量性能問題的能力需要對這些問題能夠量化，并根據重要性對不同問題進行排序。

性能分析方法可以提供一種有效的方法來分析系統或組件并識別問題的根本原因，而不需要深入的專業知識。方法論也可以提供識別和量化問題的方法，使它們被了解和排序。特定的性能檢查表已經成為一種流行的資源。然而，可觀測性僅限于列表中的特定項目，它們通常是過時且需要更新的。這些檢查列表可能關注了那些可以很容易記錄的已知問題，比如可調參數的設置，但不包括對源代碼或環境的定制補丁。

既然如此，出現了關于性能問題的常見現象。

關于系統性能的反方法論

第一種現象是『甩鍋』，常見的方式：

• 找到一個自己不負責的系統或環境組件。
• 假設問題出在那個組件上。
• 將問題轉向負責任的團隊。
• 如果被證明是錯誤的，回到第一步。

例如，“也許是網絡的問題。你能不能和網絡團隊核實一下，看看他們是否丟失了數據包之類的東西?”這種方法不是調查性能問題，而是把它們變成別人的問題，這極可能會浪費其他團隊的資源。由于缺乏數據分析，甚至從一開始就缺乏數據，導致了這一假設。

第二種方式是運行工具和收集數據，這要優于隨意的假設，但它仍不足以進行有效的性能分析，這是缺乏深思熟慮的方法。用戶通過選擇熟悉的、在互聯網上發現的或隨機發現的可觀測性工具來分析性能，然后看看是否有任何明顯的跡象出現。這種隨機應變的方法可能會忽略許多類型的問題。

找到合適的工具需要一段時間，最熟悉的工具會首先運行，即使它們不是最有意義的。學習更多的工具有所幫助，但仍然是一個有限的方法。由于缺乏可觀察性工具或指標，某些系統組件或資源可能會被忽略。此外，我們可能沒有意識到視圖是不完整的，沒有辦法識別“未知的未知”。

現有的性能分析方法

可以使用更好的性能分析方法，在運行工具之前可以解決問題，包括問題陳述方法、負載塑造法和鉆取分析法。

問題陳述法

客服或者支持人員收集問題信息時通常使用問題陳述法，可以用于性能分析。其目的是收集問題的詳細描述以指導更深入的分析，這個描述本身甚至可以解決這個問題。這通常是通過詢問以下問題進入分析環節:

• 什么會被認為存在性能問題?
• 這個系統曾經運行良好嗎?
• 最近系統有什么變化? (軟件? 硬件? 負載?)
• 性能下降是否可以用延遲或執行時間來表示?
• 這個問題是否影響到其他人或應用程序(或者只是影響到自己) ?
• 環境是什么? 使用什么軟件和硬件? 版本? 配置?

這些問題可以根據具體場景進行定制。這樣的問題看起來很明顯，答案往往也能解決了一類問題，不需要更深入的方法。當情況不是這樣時，可以調用其他方法來提供服務，包括負載塑造法和鉆取分析法。

負載塑造法

可以是有屬性的，例如:

• 負載是誰引起的? 進程 ID、用戶 ID、遠程 IP 地址?
• 為什么要產生異常負載? 可能的代碼路徑?
• 負載的其他特征是什么? IO、吞吐量、類型?
• 負載是如何隨著時間變化的?

這些問題有助于將負載問題與架構問題分離開來。最好的性能往往來自于消除不必要的工作。有時，這些瓶頸是由應用程序故障(例如，線程卡在循環中)造成的，也可能是由于錯誤配置產生的。通過維護或重新配置，這些不必要的工作可以被消除，負載塑造可以識別這類變更問題。

鉆取分析法

鉆取分析包括剝離軟件和硬件的層次，以找到問題的核心，從高到低深入到不同層次的細節。這些更深入的細節甚至包括檢查內核的內部構造，例如，通過對內核堆棧跟蹤進行取樣分析，或者通過動態跟蹤檢查內核函數的執行。

鉆取分析法包括：

• 監測，不斷地記錄許多系統隨時間變化的高級統計數據，如果出現問題，則識別或發出警報。
• 識別，如果系統存在疑似問題，這將調查范圍縮小到使用系統工具和識別可能瓶頸的特定資源或感興趣的領域。
• 分析，進一步審查特定的系統領域，找出根本原因，并將問題量化。

分析階段可以向下鉆取，從軟件堆棧頂部的應用程序開始，向下鉆取到系統庫、系統調用、內核內部、設備驅動程序和硬件。雖然向下鉆取分析常常能夠確定問題的根本原因，但是這樣做可能會耗費時間，而且當向錯誤的方向鉆取時，可能會浪費大量的時間。

有沒有更高效的方法么?

關于性能問題的早期快速定位

對于每個資源，我們可以檢查它的利用率、飽和度和錯誤。資源意味著單獨檢查的所有物理服務器功能組件(cpu、磁盤、總線等)，一些軟件資源也可以使用相同的方法進行檢查。

利用率是資源在特定時間間隔內工作時間的百分比。在忙時，資源可能仍然能夠接受更多的負載， 具體與否可以通過飽和度來確定。對于某些資源類型，例如內存，利用率是所使用資源的容量，這與基于時間的定義不同。一旦容量資源達到100% 的利用率，要么將負載(飽和度)排入隊列，要么返回錯誤。錯誤是指錯誤事件的數量，當故障模式是可恢復的時候，它們可能不會立即被注意到。這包括失敗和重試的操作，以及在冗余設備池中失敗的設備。

嘗試迭代系統資源，而不是從工具開始，創建一個要問的問題完整列表，只搜索用于回答這些問題的工具。即使找不到回答這些問題的工具，也是極其有用的，它們現在變成“已知的未知”。

嘗試指向有限數量的關鍵指標，以便盡可能快地檢查所有系統資源。在此之后，如果沒有發現問題，可以轉向其他方法。

度量指標

度量指標包括：

• 利用率：一個時間間隔內的百分比(例如，一個 CPU 的利用率為90%)。
• 飽和度：等待隊列長度(例如，CPU的平均運行隊列長度為4)。
• 錯誤報告中的錯誤數量(例如，最后50次網絡交互的沖突)。

表示測量的時間間隔也很重要。雖然看起來有些違反直覺，即使在較長的時間間隔內總利用率很低，但短時間的高利用率會導致性能問題。例如，CPU 利用率在秒級可能有很大的差異，五分鐘內的平均利用率會掩蓋達到100% 的短時間段內的飽和度問題。

資源列表

快速定位性能問題需要一個完整的資源列表，例如，一個服務器硬件資源的通用列表如下:

• CPU ー sockets、核心、硬件線程(虛擬 cpu)。
• 內存ー DRAM
• 網絡接口ー以太網口
• 儲存ー磁盤
• 控制器ー存儲、網絡。

每個組件通常是單個資源類型。例如，主存是容量資源，網絡接口是 I/O 資源，可以用 IOPS 或吞吐量來度量。有些組件可以表現為多種資源類型ー例如，存儲設備既是 I/O 資源又是容量資源，需要考慮所有可能導致性能瓶頸的類型。需要注意的是，I/O 資源可以進一步抽象為排隊系統，對這些請求進行排隊，然后為其提供服務。

高利用率或高飽和度下導致性能瓶頸的資源是最值得關注， 而緩存在高利用率下提高性能。在排除系統瓶頸之后，可以檢查緩存命中率和其他性能屬性。如果不能確定是否要包含一個資源，就包含它，然后看看這個度量指標在實踐中工作得如何。

功能模塊圖

一種遍歷資源的方法是查找或繪制系統的功能模塊圖。這種類型的圖表顯示了資源之間的關系，這在尋找數據流中的瓶頸時非常有用。在確定各種總線的利用率時，在功能圖上用其最大帶寬標注每個總線。在進行單一測量之前，可以根據功能模塊圖來探查系統瓶頸。

CPU、內存和 I/O 的互連接性常常被忽略。幸運的是，它們通常不是導致系統瓶頸的原因。不幸的是，當它們出現時，問題可能很難解決，或許需要可以升級主板或減少負載。

度量方法

一旦獲得了資源列表，需要考慮每個資源所需的度量類型(利用率、飽和度和錯誤數量)。這些指標可以表示為每個時間間隔的平均值或者計數。

注意當前那些不可用的指標:，這些“已知的未知”最終將得到一個包含大約幾十個指標的列表，其中有些很難度量，有些則根本無法度量。幸運的是，最常見的問題通常出現在更簡單的指標上，例如，CPU 飽和度、內存容量飽和度、網絡接口利用率、磁盤利用率等 ，因此可以先檢查這些指標。

其中一些指標可能無法從操作系統工具中獲得，必須使用DTrace或 CPU 性能工具編寫自己的軟件來獲得這些指標。

軟件資源

一些軟件資源也可以進行類似的檢查，通常適用于較小的軟件組件，而不適用于整個應用程序。例如:

• 互斥鎖。利用率可以定義為鎖被持有的時間，飽和度是鎖等待的線程排隊。
• 線程池。利用率可以定義為線程忙于處理工作的時間，飽和度可以定義為等待線程池處理的請求數量。
• 進程/線程容量。系統可能有數量受限的進程或線程，其當前使用可定義為利用率; 等待分配可能表明飽和度; 當分配失敗時發生錯誤。
• 文件描述符容量，與上面的類似。

如果可以正常度量，就可以使用這些指標; 否則，軟件故障排除可以留給其他方法。

性能定位的策略

性能問題定位的核心是確定使用哪些度量指標，從操作系統讀取這些指標后，需要解釋這些指標當前的值。對于某些度量指標，解釋可能是顯而易見的，并且有很好的文檔記)。如果不明顯的指標，可能取決于工作量需求或對他們的預期。錯誤排在第一位，因為它們通常比利用率和飽和度更容易、更快地進行解釋。

不幸的是，一個系統可能會遇到不止一個性能問題，首先要完成標準動作， 檢查資源表并列出所有發現的問題，然后根據可能的優先級對每個問題進行調查會更有效。

小結

系統性能分析可能是復雜的，任何組件都可能產生問題，包括它們之間的交互。常用的方法有時類似于猜測，嘗試熟悉的工具或者在沒有確鑿證據的情況下提出假設。我們可以執行一種簡單策略，對完整的系統進行健康檢查?？紤]所有的資源，以避免忽略問題，使用有限的度量，以便能夠迅速遵循，這對于分布式環境(包括云計算)尤其重要。