[性能測試實戰30講」之問題問答整理十六
- 2020 年 3 月 12 日
- 筆記
性能測試實戰30講 CentOS：作業系統級監控及常用計數器解析
思考：為什麼 CPU 是很多性能問題分析的方向性指標？
CPU 常見的計數器是 top 中的 8 個值，也就是下面這些：
%Cpu(s): 0.7 us, 0.5 sy, 0.0 ni, 98.7 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
常見的問題大部分都是體現在這麼幾個計數器上（排名有先後）：
- us
- wa
- sy
- si
讀者：
如果應用部署在k8s上 ，用top或是vmstat等命令查看都是node節點的指標，如何精確排查應用問題導致的性能問題呢
作者回復: 首先，k8s只是編排工具，容器才是應用的載體。如果你是用的k8s+docker，那就先把k8s、node（也就是你說的用top、vmstat看的部分）、docker監控起來，然後把其中的應用監控起來，這就取決於你是什麼樣的應用了。 如果是java應用，可以用專欄關於java分析部分的工具。如果是基他語言，可以用其他語言提供的分析工具。
讀者：
應用無非就是兩種計算密集型和IO密集型，計算密集集就體現在CPU忙，IO密集型就體現在CPU空閑，我想接下來無非就是圍繞這兩種類型展開分析，所以說CPU是性能分析的方向性指標。
作者回復: 理解的很正確。
- 我為什麼不建議在生產環境中一開始就上 APM 類工具來抓取方法的執行時間呢？
- 你有什麼方法可以抓取到 Java 語言中的方法執行時間？
- 如果你擅長其他語言，也可以描述其他語言中的方法執行時間抓取工具。
讀者：
我覺得某些生產環境還是可以直接上APM的： 1. 能接受10%性能損耗的，比如原來耗時1秒，上了變成1.1秒其實感覺不明顯；原來高峰期CPU使用率30%，上了變成40%也還在可接受範圍內； 2. APM的成功失敗不影響業務的運行，就是即使APM掛了，業務也還能正常運行； 3. 在docker+k8且又有大量虛機大量服務的情況下，上APM也是一個方案，不然當出現問題時要在那麼多服務裡面把問題定位到，用jmx這類監控很容易措手不及和慌手慌腳。 4. 現在好些公司沒有專職性能測試，好些系統沒有經過性能測試就上線的，此時APM是開發和運維人員的一個救命稻草了，這種公司我相信很多。
作者回復: 很不幸的是，你說的非常對。 我覺得我們對大量服務的場景其實需要的只是一個鏈路監控系統，這個功能APM基本都有提供，我們要用的就是這個功能而已。 另外，我不知道你有沒有遇到過APM的agent導致業務系統掛掉的情況，在我的工作中有遇到過，一級故障，損失也是慘重。 所以用不用APM，只有在具體的應用場景中，測試好了再決定上不上吧。
