1.什么是性能?性能指標有哪些？

計算機的性能，其實和我們干體力勞動很像，好比是我們要搬東西。對于計算機的性能，我們需要有個標準來衡量。這個標準中主要有兩個指標。第一個是響應時間（Response time）或者叫執行時間（Execution time）。想要提升響應時間這個性能指標，你可以理解為讓計算機“跑得更快”

? ? ? ? 第二個是吞吐率（Throughput）或者帶寬（Bandwidth），想要提升這個指標，你可以理解為讓計算機“搬得更多”。

所以說，響應時間指的就是，我們執行一個程序，到底需要花多少時間。花的時間越少， 自然性能就越好。而吞吐率是指我們在一定的時間范圍內，到底能處理多少事情。這里的“事情”，在計算機里就是處理的數據或者執行的程序指令。和搬東西來做對比，如果我們的響應時間短，跑得快，我們可以來回多跑幾趟多搬幾趟。所以說，縮短程序的響應時間，一般來說都會提升吞吐率。除了縮短響應時間，我們還有別的方法嗎？當然有，比如說，我們還可以多找幾個人一起來搬，這就類似現代的服務器都是 8 核、16 核的。人多力量大，同時處理數據，在單位時間內就可以處理更多數據，吞吐率自然也就上去了。提升吞吐率的辦法有很多。大部分時候，我們只要多加一些機器，多堆一些硬件就好了。但是響應時間的提升卻沒有那么容易，因為 CPU 的性能提升其實在 10 年前就處于“擠牙膏”的狀態了，所以我們得慎重地來分析對待。

下面我們具體來看。我們一般把性能，定義成響應時間的倒數，也就是：性能 = 1/ 響應時間這樣一來，響應時間越短，性能的數值就越大。同樣一個程序，在 Intel 最新的 CPU Coffee Lake 上，只需要 30s 就能運行完成，而在 5 年前 CPU Sandy Bridge 上，需要 1min 才能完成。那么我們自然可以算出來，Coffee Lake 的性能是 1/30，Sandy Bridge 的性能是 1/60，兩個的性能比為 2。于是，我們就可以說，Coffee Lake 的性能是 Sandy Bridge 的 2 倍。過去幾年流行的手機跑分軟件，就是把多個預設好的程序在手機上運行，然后根據運行需要的時間，算出一個分數來給出手機的性能評估。而在業界，各大 CPU 和服務器廠商組織了一個叫做?SPEC（Standard Performance Evaluation Corporation）的第三方機構，專門用來指定各種“跑分”的規則。

2.如果性能不達標怎么辦？

使用Profiler性能分析器首先確定性能瓶頸出現在哪里，定位性能問題出現的根本原因，按照具體原因去做優化。

通常來說，性能問題大致出現在兩個方面：

1.細節不夠好(資源問題、插件問題、代碼寫法問題)

2.結構不夠好(框架問題、底層API問題)

細節問題解決成本低，可以獨立調整，對其他部分影響小，可以批量解決。

結構問題解決成本高，牽一發動全身，對其他部分影響大，需要大修、大測。

由于游戲整體是由各個細節組成的，所以當細節做的不夠好時，整體也會顯現出問題。

反之當結構不夠好時，細節即使做的很好，游戲整體表現出的性能也不會太好，兩者是相輔相成的。

我的建議是：用嚴格認真的態度控制細節，用豐富的經驗積累出可靠的結構。

前者靠態度，后者靠經驗。當我們經驗不多時，應該依靠態度嚴控細節，當我們經驗足夠時，兩方面都要兼顧。

調優策略：追求基于滿足訴求的精度條件下的性能提升。但是，如果性能已經達到無法接受的程度，那么就先解決性能，處理到可接受為止。
精度調優過程中導致性能惡化，或者性能調優過程中導致精度惡化，記住兩點：
1、千萬不要兜圈子，不要精度差了搞精度，性能差了又搞性能。
2、有階段成果后，后續的嘗試和修改一定要分步驟執行，做好記錄

3.訓練服務器的演示及簡介

Atlas 800 訓練服務器（型號9000）是基于華為鯤鵬920+昇騰910處理器的AI訓練服務器，實現完全自主可控，廣泛應用于深度學習模型開發和AI訓練服務場景。該服務器面向公有云、互聯網、運營商、政府、交通、金融、高校、電力等領域，具有高計算密度、高能效比、高網絡帶寬、易擴展、易管理等優點，支持單機和整機柜銷售，支持風冷和液冷應用，滿足企業機房部署和大規模數據中心集群部署。

計算產品3D展示 (huawei.com)

大家可以使用上面的地址進行3D模型預覽及展示，可以看這個服務器的構造及拆解組件，體驗感十足。

這個性能分析在昇騰全棧AI軟硬件平臺主要體現在標記的異構計算架構部分，釋放硬件的算力。

4.訓練執行的過程是什么樣的？

OBS資源圖里有很多細分的圖表，其實不需要全部記住，因為每個指標的變化都不是獨立的，是與其他指標關聯的

1、每秒點擊數

每秒點擊數（Hits per Second）統計的是運行場景過程中，虛擬用戶每秒向Web服務器提交的HTTP請求數。該指標經常與其他指標結合進行分析

2、吞吐量

吞吐量（Throughput）統計場景運行過程中服務器的每秒吞吐量，單位是字節，表示虛擬用戶在任何給定的每一秒內，從服務器獲得的數據量。通過該指標可以看出服務器在流量方面的處理能力以及是否存在瓶頸，正常情況下，吞吐量與TPS圖的變化基本一致。若壓力增大時，吞吐量的曲線增加到一定程度后變化緩慢，甚至平坦，則很可能是網絡出現帶寬瓶頸。不論是吞吐量，還是TPS都非常不穩定，尤其是TPS，通過率比較低

3、HTTP狀態碼概要

HTTP狀態碼概要（HTTP Status Code Summary）統計場景運行過程中，從Web服務器返回的HTTP狀態代碼數，返回的都是200狀態碼，說明在HTTP返回層面上是成功的

4、每秒HTTP響應數

每秒HTTP響應數（HTTP Responses per Second）統計運行場景過程中，每秒從Web服務器返回的不同HTTP狀態碼的數量。一般和每秒點擊量相同，如果服務器的響應數小于點擊量，那么說明服務器無法應答，超過負載的鏈接請求

5、連接數

連接數（Connections）統計場景運行過程中，每個時間點打開的TCP/IP連接數。例如，當連接數dadao 穩定狀態而事務響應時間迅速增大時，添加連接可以使用性能得到極大提高

6、每秒連接數

每秒連接數（Connections Per Second）統計新建的連接數和關閉的連接數，方便了解每秒對服務器產生連接的數量。同時連接數越多，說明服務器的連接池越大，當連接數隨著負載上升而停止時，說明系統的連接池已滿，通常這個時候服務器會返回504錯誤

7、每秒重試次數

每秒重試次數圖顯示在場景運行的每一秒內，服務器嘗試的連接次數。在下列情況下將重試服務器連接

初始連接未經授權

要求代理服務器身份驗證

服務器關閉了初始連接

初始連接無法連接到服務器

服務器最初無法解析負載生成器的IP地址

8、每秒SSL連接數

每秒SSL連接數圖顯示在場景運行的每一秒內，重新使用的SSL連接數。當對安全服務器打開TCP/IP連接后，瀏覽器打開SSL連接。因為新建SSL連接需要消耗大量的資源，所以應該盡量減少打開新的SSL連接。建立新SSL連接后，應該重復使用該連接。每個虛擬用戶的新SSL連接數不應該超過一個。理想情況下，每秒都應該只有很少量的新TCP/IP和SSL連接.

5.將整網訓練階段進行分段，分析性能影響

1).數據讀取階段：主要影響在HOST側

2).數據預處理階段：HOST和DEVICE都可能涉及

3).訓練后處理階段：HOST和DEVICE都可能涉及

相關文檔Log/Summary_昇騰CANN社區版(5.0.3 alpha 001)(訓練)_TensorFlow模型遷移和訓練_手工遷移和訓練_更多特性_華為云 (huaweicloud.com)

4）.訓練執行階段：主要影響在DEVICE側

6.打開Profiling前，確認當前源碼狀態(確認當前源碼處在手工遷移后的狀態)

原始的代碼： sess=tf.Session() 自動遷移后的代碼： sess = tf.Session(config=npu_config_proto()) 手工遷移后的代碼： config = tf.ConfigProto() custom_op = config.graph_options.rewrite_options.custom_optimizers.add() custom_op.name = "NpuOptimizer" config.graph_options.rewrite_options.remapping = RewriterConfig.OFF config.graph_options.rewrite_options.memory_optimization = RewriterConfig.OFF sess = tf.Session(config=config)

設置Profiling開關，打開Profiling

手工遷移后的代碼： config = tf.ConfigProto() custom_op = config.graph_options.rewrite_options.custom_optimizers.add() custom_op.name = "NpuOptimizer" config.graph_options.rewrite_options.remapping = RewriterConfig.OFF config.graph_options.rewrite_options.memory_optimization = RewriterConfig.OFF sess = tf.Session(config=config) 設置profiling后的代碼： config = tf.ConfigProto() custom_op = config.graph_options.rewrite_options.custom_optimizers.add() custom_op.name = "NpuOptimizer" custom_op.parameter_map["profiling_mode"].b = True custom_op.parameter_map["profiling_options"].s = tf.compat.as_bytes('{"output":"/mypath/output","task_trace":"on","training_trace":"on","aicpu":"on","fp_point":"","bp_point":""}') config.graph_options.rewrite_options.remapping = RewriterConfig.OFF config.graph_options.rewrite_options.memory_optimization = RewriterConfig.OFF sess = tf.Session(config=config)

操作手冊請參考功能介紹_昇騰CANN社區版(5.0.3 alpha 001)(訓練)_開發輔助工具_Profiling工具使用指南_概述_華為云 (huaweicloud.com)

7.總結：遇到性能問題時，推薦的debug順序和手段是什么樣的？

core dump的調試

首先說一下core的解決思路，主要是如下幾點：

gdb及debug log定位，發現作用不大。

如何重現bug？

構造高并發壓力測試系統。

構造穩定的異常請求。

使用TC(traffic control)工具來構造弱網絡環境，但是轉念一想，弱網絡環境導致的結果是什么？顯然是網絡請求的各種異常啊,所以還不如直接構造各種異常請求來復現問題。于是準備構造測試工具和環境，需要滿足兩個條件：

并發性能強，能夠同時發送數萬甚至數十萬級以上qps。

請求需要一定概率的異常。特別是TCP握手及SSL握手階段，需要異常中止。

WRK壓力測試工具

由于高并發流量時才可能出core，所以首先就需要找一個性能強大的壓測工具。
WRK是一款非常優秀的開源HTTP壓力測試工具，采用多線程 + 異步事件驅動的框架，其中事件機制使用了redis的ae事件框架，協議解析使用了nginx的相關代碼。
相比ab（apache bench）等傳統壓力測試工具的優點就是性能好，基本上單臺機器發送幾百萬pqs,打滿網卡都沒有問題。
wrk的缺點就是只支持HTTP類協議，不支持其他協議類測試，比如protobuf，另外數據顯示也不是很方便。

nginx的測試用法：wrk -t500 -c2000 -d30s https://127.0.0.1:8443/index.html

linux世界有許多非常好用的性能分析工具，我挑選幾款最常用的簡單介紹下：
1. [perf](Perf Wiki)應該是最全面最方便的一個性能檢測工具。由linux內核攜帶并且同步更新，基本能滿足日常使用。**推薦大家使用**。
2. oprofile，我覺得是一個較過時的性能檢測工具了，基本被perf取代，命令使用起來也不太方便。比如opcontrol --no-vmlinux , opcontrol --init等命令啟動，然后是opcontrol --start， opcontrol --dump， opcontrol -h停止，opreport查看結果等，一大串命令和參數。有時候使用還容易忘記初始化，數據就是空的。
3. gprof主要是針對應用層程序的性能分析工具，缺點是需要重新編譯程序，而且對程序性能有一些影響。不支持內核層面的一些統計，優點就是應用層的函數性能統計比較精細，接近我們對日常性能的理解，比如各個函數時間的運行時間，，函數的調用次數等，很人性易讀。
4. systemtap 其實是一個運行時程序或者系統信息采集框架，主要用于動態追蹤，當然也能用做性能分析，功能最強大，同時使用也相對復雜。不是一個簡單的工具，可以說是一門動態追蹤語言。如果程序出現非常麻煩的性能問題時，推薦使用 systemtap。

這里再多介紹一下perf命令，tlinux系統上默認都有安裝，比如通過perf top就能列舉出當前系統或者進程的熱點事件，函數的排序。
perf record能夠紀錄和保存系統或者進程的性能事件，用于后面的分析，比如火焰圖。

調試BUG是一次非常難得的學習機會，不要把它看成是負擔。不管是線上還是線下，能夠主動地，高效地追查BUG特別是有難度的BUG，對自己來說一次非常寶貴的學習機會。面對這么好的學習機會，自然要充滿熱情，要如饑似渴，回首一看，如果不是因為這個BUG，我也不會對一些工具有更深入地了解和使用，也就不會有這篇文檔的產生。

不管什么樣的BUG，隨著時間的推移，肯定是能夠解決的。這樣想想，其實會輕松很多，特別是接手新項目，改造復雜工程時，由于對代碼，對業務一開始并不是很熟悉，需要一個過渡期。但關鍵是，你要把這些問題放在心上。白天上班有很多事情干擾，上下班路上，晚上睡覺前，大腦反而會更加清醒，思路也會更加清晰。特別是白天上班時容易思維定勢，陷入一個長時間的誤區，在那里調試了半天，結果大腦一片混沌。睡覺前或者上下班路上一個人時，反而能想出一些新的思路和辦法。

開放的討論。遇到問題不要不好意思，不管多簡單，多低級，只要這個問題不是你google一下就能得到的結論，大膽地，認真地和組內同事討論。方法總比困難多！

好啦，本期內容孫叫獸就分享到這里，我們下期見！

總結

以上是生活随笔為你收集整理的知道这些性能优化手段，工资起码提升一倍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。