計算機性能是一門令人激動的，富于變化同時又充滿挑戰(zhàn)的領(lǐng)域。

系統(tǒng)性能是對整個計算機系統(tǒng)的性能的研究，包括主要硬件組件和軟件組件。所有數(shù)據(jù)路徑上和從存儲設(shè)備到應(yīng)用軟件上所發(fā)生的事情都包括在內(nèi)，因為這些都有可能影響性能。對于分布式系統(tǒng)來說，這意味著多臺服務(wù)器和多個應(yīng)用。如果你還沒有關(guān)于你的環(huán)境的一張示意圖，用來顯示數(shù)據(jù)的路徑，趕緊找一張或者自己畫一張。它可以幫助你理解所有組件的關(guān)系，并確保你不會只見樹木不見森林。

系統(tǒng)性能的典型目標是通過減少延時和降低計算成本來改善終端用戶的體驗。降低成本可以通過消除低效之處、提高系統(tǒng)吞吐量和進行常規(guī)性能調(diào)優(yōu)來實現(xiàn)。

下面是系統(tǒng)性能的一些重要概念

延時對于某些環(huán)境，延時是被唯一關(guān)注的性能焦點。而對于其他環(huán)境，它會是除了吞吐量以外，數(shù)一數(shù)二的分析要點。

作為延時的一個例子，圖 2.3 顯示了如 HTTP GET 請求的網(wǎng)絡(luò)傳輸，其響應(yīng)時間被分成連接延時和數(shù)據(jù)傳輸時間兩部分。

延時是操作執(zhí)行之前所花的等待時間。在這個例子里，操作是網(wǎng)絡(luò)服務(wù)的數(shù)據(jù)傳輸請求。在這個操作發(fā)生之前，系統(tǒng)必須等待建立網(wǎng)絡(luò)連接，這就是這個操作的延時。響應(yīng)時間包括了延時和操作時間。

因為延時可以在不同點測量，所以通常會指明延時測量的對象。例如，網(wǎng)站的載入時間由三個從不同點測得的不同時間組成 ：DNS 延時、TCP 連接延時和 TCP 數(shù)據(jù)傳輸時間。DNS 延時指的是整個 DNS 操作的時間，TCP 連接延時僅僅指的是初始化時間（TCP 握手）。

由于延時是一個時間上的指標，因此可能有多種計算方法。性能問題可以用延時來進行量化和評級，因為是用相同的單位來表達的（時間）。通過考量所能減少或移除的延時，預(yù)計的加速也可以被計算出來。這兩者不能用 IOPS 指標很準確地描述出來。

時間的量級和縮寫列在了表 2.1 中，可作為參考。

如果可能，其他的指標也會轉(zhuǎn)化為延時或者時間，這樣就可以進行比較了。如果必須在 100 個網(wǎng)絡(luò) I/O 和 50 個磁盤 I/O 之間做出選擇，怎樣才能知道哪個性能更好？這是一個復(fù)雜的選擇，因為其中包含了很多因素 ：網(wǎng)絡(luò)跳數(shù)、網(wǎng)絡(luò)丟包率和重傳率、I/O 的大小、隨機或順序的 I/O、磁盤類型，等等。但是如果你比較的是 100ms 的網(wǎng)絡(luò) I/O 延時和 50ms 的磁盤 I/O 延時，那差別就很明顯了！

時間量級我們可以對時間進行量化的比較，同時最好對時間和各種來源的延時的合理預(yù)期有本能的認識。系統(tǒng)各組件的操作的時間量級差別巨大，表 2.2 中提供的延時示例，從訪問 3.5GHz 的 CPU 寄存器的延時開始，闡釋了各種操作時間量級的差別。表中所示的是發(fā)生單次操作的時間均值，等比放大為一個假想的系統(tǒng)，將 1 個 CPU 周期的 0.3ns（十億分之一秒的三分之一 1）放大為現(xiàn)實生活中的 1 秒。

正如你所見，1 個 CPU 周期的時間是很短暫的。0.5 米差不多是你的眼睛到這個頁面的距離，光線走過這段距離需要的時間大約是 1.7ns。在這段時間里，現(xiàn)代的 CPU 已經(jīng)執(zhí)行了 5 個 CPU 周期，處理了若干個指令。

權(quán)衡你應(yīng)該知道某些性能權(quán)衡關(guān)系。圖 2.4 展示的是好 / 快 / 便宜“擇其二”的權(quán)衡關(guān)系，右圖所示的是對應(yīng)于 IT 項目的術(shù)語。

許多 IT 項目選擇了及時和成本低，留下了性能問題在以后解決。當早期的決定阻礙了性能提高的可能性時，這樣的選擇會變得有問題，例如，選擇了非最優(yōu)的存儲架構(gòu)，或者使用的編程語言或操作系統(tǒng)缺乏完善的性能分析工具。

一個常見的性能調(diào)優(yōu)的權(quán)衡是在 CPU 與內(nèi)存之間，因為內(nèi)存能用于緩存數(shù)據(jù)結(jié)果，降低 CPU 的使用率。在有著充足 CPU 資源的現(xiàn)代系統(tǒng)里，交換可以反向進行 ：CPU 可以壓縮數(shù)據(jù)來降低內(nèi)存的使用。

調(diào)優(yōu)的影響性能調(diào)優(yōu)實施在越靠近工作執(zhí)行的地方效果最顯著。對于工作負載驅(qū)動的應(yīng)用程序，這意味著調(diào)優(yōu)性能的地方就在應(yīng)用程序本身。表 2.3 展示了一個軟件棧的例子，說明了性能調(diào)優(yōu)的各種可能。

對應(yīng)用程序?qū)蛹夁M行調(diào)優(yōu)，可能通過消除或減少數(shù)據(jù)庫查詢獲得很大的性能提升（例如，20 倍）。在存儲設(shè)備層級進行調(diào)優(yōu)，可以精簡或提高存儲 I/O，但是性能提升的重要部分在更高層級的操作系統(tǒng)棧代碼，所以對存儲設(shè)備層級的調(diào)優(yōu)對應(yīng)用程序性能的提升有限，是百分比量級的（例如，20%）。

在應(yīng)用程序?qū)蛹墝で笮阅艿木薮筇嵘?，還有一個理由。如今許多環(huán)境都致力于特性和功能的快速部署，按每周或每天將軟件的變更推入生產(chǎn)環(huán)境。 因此，應(yīng)用程序的開發(fā)和測試傾向于關(guān)注正確性，在部署前留給性能測量和優(yōu)化的時間很少甚至沒有。之后當性能成為問題時，才會去做這些與性能相關(guān)的事情。

雖然發(fā)生在應(yīng)用程序?qū)蛹壍恼{(diào)優(yōu)效果最顯著，但這個層級不一定是觀測效果最顯著的層級。數(shù)據(jù)庫查詢緩慢最好從其所花費的 CPU 時間、文件系統(tǒng)和所執(zhí)行的磁盤 I/O 方面來考查。使用操作系統(tǒng)工具，這些都是可以觀測到的。

合適的層級不同的公司和環(huán)境對性能有著不同的需求。你可能加入過這樣的公司，其分析標準要比你之前所見過的嚴格得多，甚至可能聽都沒聽過?；蛘呤沁@樣的公司，你覺得很基本的分析被認為很高端甚至從未使用過（這是好消息 ：事情簡單輕松?。?/p>

這并不意味著某些公司做的是對的，某些做的是錯的。這取決于性能技術(shù)投入的投資回報率（ROI）。擁有大型數(shù)據(jù)中心或大型云環(huán)境的組織可能會雇用一個性能工程師團隊來分析所有的事情，包括內(nèi)核內(nèi)部和 CPU 性能計數(shù)器，并頻繁使用各種跟蹤工具。他們還可能對性能進行正式建模，并對未來的增長進行準確預(yù)測。對于每年在計算上有數(shù)百萬花費的環(huán)境來說，雇用這樣一個性能團隊是值得的，因為他們進行的優(yōu)化就是投資回報。小型創(chuàng)業(yè)公司的計算開支不大，可能只進行表面的檢查，利用第三方監(jiān)測方案來檢查性能和提供警報。

何時停止分析做性能分析時的一個挑戰(zhàn)是如何知道何時停止。有這么多的工具，有這么多的東西要檢查！

當我教性能課程時（最近我又開始教了），我給我的學(xué)生一個有三個原因的性能問題，我發(fā)現(xiàn)有些學(xué)生在找到一個原因后就停止了，有些則是兩個，有些則是三個。有些學(xué)生則繼續(xù)努力，試圖為性能問題找到更多的原因。誰的做法是正確的？說你應(yīng)該在找到所有三個原因后就停止，可能很容易，但對于現(xiàn)實生活中的問題，你并不知道原因的數(shù)量。

這里有三種情況，你可以考慮停止分析，并提供了一些個人的例子。

當你已經(jīng)解釋了大部分性能問題的時候。一個 Java 應(yīng)用程序消耗的 CPU 資源是原來的 3 倍。我發(fā)現(xiàn)的第一個問題是異常堆棧消耗了 CPU。然后我量化了這些堆棧的時間，發(fā)現(xiàn)它們只占整個 CPU 占用的 12%。如果這個數(shù)字接近 66%，我就可以停止分析了。但在這種情況下，在 12% 的情況下，我需要繼續(xù)尋找。

當潛在的投資回報率低于分析的成本的時候。我所處理的一些性能問題可以帶來每年數(shù)千萬美元的收益。對于這些問題，我可以證明花幾個月的時間（工程成本）進行分析是合理的。其他的性能問題，比如說微服務(wù)，可能是以數(shù)百美元計算的，甚至不值得花 1 個小時的工程時間來分析它們。例外情況可能包括 ：當我沒有更好的事情可做時（這在實踐中從未發(fā)生過），或者如果我懷疑這可能是日后更大問題的隱患，值得在問題擴大之前進行調(diào)試時。

當其他地方有更大的投資回報率的時候。即使前兩種情況沒有得到滿足，其他地方有更大的投資回報時經(jīng)常需要優(yōu)先考慮。如果你是全職的性能工程師，根據(jù)潛在的投資回報率對不同的問題進行有選擇的分析可能是一項日常工作。

性能推薦的時間點環(huán)境的性能特性會隨著時間改變，更多的用戶、新的硬件、升級的軟件或固件都是變化的因素。一種環(huán)境，受限于速度 10Gb/s 的網(wǎng)絡(luò)基礎(chǔ)設(shè)施，當升級到 100Gb/s 時，很可能會發(fā)現(xiàn)磁盤或 CPU 的性能變得緊張。

性能推薦，尤其是可調(diào)優(yōu)的參數(shù)值，僅僅在一段特定時間內(nèi)有效。一周內(nèi)從性能專家那里得到的好建議，可能到了下一周，經(jīng)過一次軟件或硬件升級，或者用戶增多后就無效了。

在網(wǎng)上搜索找到的調(diào)優(yōu)參數(shù)值對于某些情況可能能快速見效。但如果對于你的系統(tǒng)或者工作負載并不合適，它們也可能會對性能有所損害，或者合適過一次，就不再合適了，或者只是作為軟件的某個 bug 修復(fù)升級之前暫時的應(yīng)急措施。這和從別人的醫(yī)藥箱里拿藥吃很像，那些藥可能不適合你，或者可能已經(jīng)過期，或者只適合短期服用。

如果僅僅是出于要了解有哪些參數(shù)可調(diào)以及哪些參數(shù)在過去是需要調(diào)整的，那么瀏覽這些性能建議是有用的。針對你的系統(tǒng)和工作負載，這項工作就變成了考慮這些參數(shù)是不是要調(diào)，以及調(diào)整成什么值。如果其他人不需要調(diào)整那個值，或者調(diào)整了但并未將經(jīng)驗分享出來，那么你有可能漏掉了重要的參數(shù)。

負載與架構(gòu)應(yīng)用程序性能差可能是因為軟件配置和硬件的問題，也就是它的架構(gòu)和實現(xiàn)問題。另外，應(yīng)用程序性能差還可能是由于有太多負載，而導(dǎo)致了排隊和長延時。負載和架構(gòu)見圖 2.5。

如果對架構(gòu)的分析顯示只是工作任務(wù)在排隊，處理任務(wù)沒有任何問題，那么問題就可能出在施加的負載太多上。在云計算環(huán)境里，這是需要引入更多的服務(wù)器實例來處理任務(wù)的征兆。

舉個例子，架構(gòu)的問題可能是一個單線程的應(yīng)用程序在單個 CPU 上忙碌，從而導(dǎo)致請求排隊，但是其他的 CPU 卻是可用且空閑的。在這個例子里，性能就被應(yīng)用程序的單一線程架構(gòu)限制住了。架構(gòu)的另一個問題可能是一個程序的多個線程爭奪一個鎖，這樣只有一個線程可以向前推進，而其他線程在等待。

負載的問題可能會是一個多線程程序在所有的 CPU 上都忙碌，但是請求依然排隊的情況。在這個例子里，性能可能被限制于 CPU 的性能，或者說是負載超出了 CPU 所能處理的范圍。

指標性能指標是由系統(tǒng)、應(yīng)用程序，或者其他工具選定的統(tǒng)計數(shù)據(jù)，用于測量感興趣的活動。性能指標用于性能分析和監(jiān)測，可以由命令行提供數(shù)據(jù)，也可以由可視化工具提供圖表。

常見的系統(tǒng)性能指標如下。

吞吐量 ：每秒的數(shù)據(jù)量或操作量。

IOPS ：每秒的 I/O 操作數(shù)。

使用率 ：資源的繁忙程度，以百分比表示。

延時 ：操作時間，以平均數(shù)或百分數(shù)表示。

吞吐量的使用取決于上下文環(huán)境。數(shù)據(jù)庫吞吐量通常用來度量每秒查詢或請求的數(shù)目（操作量）。網(wǎng)絡(luò)吞吐量度量的是每秒傳輸?shù)谋忍財?shù)或字節(jié)數(shù)（數(shù)據(jù)量）。IOPS 度量的是吞吐量，但只針對 I/O 操作（讀取和寫入）。再次重申，上下文很關(guān)鍵，上下文不同，定義可能會有不同。

緩存緩存被頻繁使用來提高性能。緩存是將較慢的存儲層的結(jié)果存放在較快的存儲層中。

把磁盤的塊緩存在主存（RAM）中就是一例。

一般使用的都是多級緩存。CPU 通常利用多級硬件緩存作為主緩存（L1、L2 和L3），開始是一個非?？斓呛苄〉木彺妫↙1），后續(xù)的 L2 和 L3 逐漸增加了緩存容量和訪問延時。這是一個在密度和延時之間經(jīng)濟上的權(quán)衡。緩存的級數(shù)和大小的選擇以CPU 芯片內(nèi)可用空間為準，確保達到最優(yōu)的性能。

一個了解緩存性能的重要指標是每個緩存的命中率—所需數(shù)據(jù)在緩存中被找到的次數(shù)（hits，命中）與總訪問次數(shù)（hits+misses）的比例。

命中率 = 命中次數(shù) /（命中次數(shù) + 失效次數(shù)）

命中率越高越好，更高的命中率意味著更多的數(shù)據(jù)能成功地從較快的介質(zhì)中訪問獲得。

98% 和 99% 之間的性能差異要比 10% 和 11% 之間的性能差異大很多。由于緩存命中和失效之間的速度差異（兩個存儲層級），導(dǎo)致了這是一條非線性曲線。兩個存儲層級速度差異越大，曲線越陡峭。

已知的未知已知的已知、已知的未知、未知的未知在性能領(lǐng)域是很重要的概念。下面是詳細的解釋，并提供了系統(tǒng)性能分析的例子。

已知的已知 ：有些東西你知道。你知道你應(yīng)該檢查性能指標，你也知道它的當前值。舉個例子，你知道你應(yīng)該檢查 CPU 使用率，而且你也知道當前均值是10%。

已知的未知 ：有些東西你知道你不知道。你知道你可以檢查一個指標或者判斷一個子系統(tǒng)是否存在，但是你還沒去做。舉個例子，你知道你能用剖析檢查是什么致使 CPU 忙碌，但你還沒去做這件事。

未知的未知 ：有些東西你不知道你不知道。舉個例子，你可能不知道設(shè)備中斷可以消耗大量 CPU 資源，因此你對此并不做檢查。在性能領(lǐng)域，“你知道的越多，你不知道的也就越多”。這和學(xué)習(xí)系統(tǒng)是一樣的原理：你了解的越多，你就能意識到未知的未知越多，然后這些未知的未知會變成你可以去查看的已知的未知。

原文標題：Go 性能：你知道的越多，不知道的也就越多

文章出處：【微信公眾號：馬哥Linux運維】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。