###### tags: `Linux`, `SRE` # SRE 讀書會 Round 4 #04 - 線上讀書會共筆 ## 活動資訊 * Date: 2020/06/03 (四) 20:00 - 21:30 * [導讀進度表](https://docs.google.com/spreadsheets/d/1Lgti3mILkvwxyzklX1vvLraaGD-7ePK9rkmlulfOknE/edit#gid=0) * [導讀 Guideline](https://study-area.sre.tw/GuideLine/) * Github: [study-area-docs](https://github.com/cross-community/study-area-docs) --- # 11 | 套路篇：如何迅速分析出系統CPU的瓶頸在哪裡？ - 分享者：Winnie ## 問題 * 大家常用的工具？ * 分析的步驟 1. top 2. vmstat 3. pidstat 4. process 分析工具 * 思考題 * valgrind * gprof * 分享： * 分散式儲存的研究經驗 - 邱牛 * 以商業角度出發，利用效能工具評估， 選擇效能較好的 Open Source * perf - 以 function 為單位 -- # 12 | 套路篇：CPU 性能優化的幾個思路 - 分享者：陳龍星 ＆ 曾義格 #### 回顧 CPU 性能指標 * 三個問題 * 如何判斷現在做的優化是否有效？優化後能提升多少性能？ * 確認性能的量化指標 * 找出影響最大的點 * 找出因果關係 * CPU loading 最容易觀測 * * 多個性能問題同時發生時，要先優化哪個？ * **最先達到上限的資源指標** * 多種優化方法，先選哪種？ * 優化不代表沒成本 e.g. Data Plane Developement Kit - 時空背景 2010 年開源 / 為了解決 10G 網卡問題 * 補充：DPDK 最大的成本就是要重新撰寫既有應用程式，因為原本使用的 Library 都不能使用 * 切莫因小優化而損失更大項 * 勿想一步登天 * 不是所有問題都要優化 * **先做沒副作用的** * **做最簡單快速並且其他指標副作用不會達到上限的** * 補充：量化指標 * 系統資源 * 漸進式優化 * ~~系統~~系統環境 * 命令 / 腳本 * 環境參數 (為何劃掉前三項？不患寡，患不均) * ~~CPU綁定~~ * ~~CPU獨占~~ * ~~NUMA~~: L3 cache for multi cpu core * irqbalance: 比樓上 3 個重要 * renice: 很常用 * cgroups * FC 2010: 200 lines code, but performed well * 當時解決影片, FPS 等問題 * ~~當時不能調度IO~~，即調度的功能較少V * 到 k8s? (docker?) 後才紅起來 <-- 有誰能幫忙更正 : 容器時代夯起來,200 line事件也夯一次(LongSing) * swappiness - Server: game server, swappiness = 0，因需要超低延遲，[補充資料](https://askubuntu.com/questions/943165/is-a-swappiness-value-of-0-safe-how-about-1-what-is-the-minimum) - android: swappiness = 100% ，因為記憶體太小，Android 使用了 zram 的技術：LRE 只壓縮零 - JAVA_OPTS - G1GC: JAVA 8 以後支援 - XSS: 256k 建議採用 - UseAVX , UseSSE：可以優化運行速度 - Compile Threshold=8000 (8192) - XX Background Compliation：背景編譯 - G1GCPauseMillis=200 (ms) 建議採用 * 定時腳本 * 執行參數 * 最常加的是 Nice * 編譯參數 * Kernal 優化 * 不用寫程式，進入 menu config 就可以設定參數優化系統 * 程式碼 * 服務架構 * 程式碼可能要換個寫法增進服務效能 * * 問題 * SWAP 要如何設定比較好? * 看服務應用類型選擇(LongSing) * 重編(優化) kernel 的場景多嗎? * 我每天都在看是否有核心更新,當刷核心已成習慣XD(LongSing) # 13 | 答疑（一）：無法模擬出 RES 中斷的問題，怎麼辦？ - 分享者：Hans Hsu # 現場共筆 - 為什麼殭屍程序要存在？ - smp_affinity：用來控制 IRQ 分配的方式，某些情況會希望近可能讓特定 CPU 來處理中斷 - 中斷： - 上半部：不應該睡眠或 lock (spin lock、busy lock 除外) - 下半部：可以不用馬上處理，比方說進 work queue 慢慢處理 - 硬中斷、軟中斷如何判斷：誰是中斷的源頭 - 硬碟要求（網卡、memory 等等） - 軟體作為源頭（除以 0、指到空指標），有 user 在做驅動 - ApacheBench 做測試 - 類似工具(http)：hey, wrk, [siege](https://github.com/JoeDog/siege) - tcp: iperf3, pktgen --- # 參考資料