HackMD
YAMLException: can not read a block mapping entry; a multiline key may not be an implicit key at line 2, column 5:
tags: "Linux", "SRE"
^
title: [SRE 讀書會] Round 4 線上讀書會共筆-01
tags: "Linux", "SRE"
活動資訊
- Date: 2020/04/23 (四) 20:00 - 21:30
- 導讀進度表
- 導讀 Guideline
- Github: study-area-docs
Slides
- 01 | 如何學習Linux性能優化？ - Rick
- 02 | 基礎篇:到底應該怎麼理解“平均負載”? - 阿福
- 03 | 基礎篇：經常說的 CPU 上下文切換是什麼意思？（上） - 阿瑋
- 04 | 基礎篇：經常說的 CPU 上下文切換是什麼意思？（下） - 阿瑋
現場共筆
如何快速入門
- 技巧一：雖然系統的原理很重要，但在剛開始一定不要試圖抓住所有的實現細節
- 不需要瞭解
- 每個元件的所有實現細節
- 每個人的所有心裡的想法
- 只要能理解
- 最基本的工作原理&特性
- 瞭解 Linux 常用命令的使用方法
- 知道怎麼安裝和管理軟件包
- 知道怎麼通過程式編程語言開發應用程序等
- 協作方式
- 最基本的工作原理&特性
- 不需要瞭解
- 技巧二：邊學邊實踐，通過大量的案例演習掌握 Linux 性能的分析和優化
- 進行大量的實戰練習，建立起整體效能的全局觀
- 實做>理論
- 技巧三：勤思考，多反思，善總結，多問為什麼
效能
指標
- 應用負載: 直接影響了產品終端的用戶體驗 (End User)
- 高並發 (High Concurrency): 系統能是否同時處理大量用戶發出請求的能力
- 響應快 (Quick Response)
- 系統資源: 資源使用率、飽和度
- 吞吐量 (Througtput): 時間內可處理的請求數量
- 延遲時間 (Latency)
分析流程
- 選擇指標，評估應用程式和系統效能 → SLI (Service Level Indicator)
- 為應用程式和系統設置效能目標 → SLO (Service Level Objective)
- 進行效能基準測試 → Benchmark、Capacity
a. 如何量測系統的容量？（壓力測試） - 效能分析定位瓶頸 → Bottlebeck
a. 系統發生異常時，第一時間如何快速止血？ - 改善 (優化) 系統和應用程式 → 重構
- 效能監控和告警
系統平均負載
- 代表一段時間內的系統工作量
- 影響因素
- CPU
- I/O
- 影響因素
- 是指在可運行或不可中斷狀態下的進程平均數量。
- 可運行狀態：進程正在使用CPU或等待使用CPU。
- 不可中斷狀態：進程等待某些I/O訪問，例如等待磁盤。
- 平均負載
- 數據是基於三個時間間隔（1分鐘、5分鐘、15分鐘）計算的。
- 計算公式：平均負載 = 可運行＋不可中斷進程數量 / 時間區間（1、5、15分鐘）
- 未根據系統中的CPU數量進行標準化(
System load averages != CPU usage%)- 為1表示單CPU系統一直處於負載狀態
- 4 CPU系統中則表示系統閒置75%的時間
- 1 件事情不代表很閒,但一定要知道幫你工作的人有多少位(Core)
- 數據是基於三個時間間隔（1分鐘、5分鐘、15分鐘）計算的。
- uptime(htop) 比起第一個數據，更要注意第二、三數據
- Zabbix 的監測結果跟 "top/uptime" 沒有一致
- 因為不同軟體的實作方式都有差異
- 實際上 Zabbix 採用的是讀取
/proc/stat來進行計算- 相關的內容在 zabbix
- fio 此工具可以針對不同的寫 block 的方式做壓測
- buffer的地方滿多的
- 從 library -> kernel -> disk 三層都有
- 有興趣的可以閱讀這篇文章 Ensuring data reaches disk
- 在書本裡面的範例出現的問題應該是在 kernel buffer
Context switch
context-switch vs. system call ?
- 大部分system call 是權限轉換
- 不能直接兩者比較，要看system call的過程中是否有context-switch
- process and thread
- 差別在 heap
- Process/Thread context-switch 保存跟恢復狀態需要讀寫硬體(Memory)
- 我們可以藉由工具觀測 context-switch 以及 interrupt 來判斷 CPU 的使用狀況，
- 如果系統資源耗費在不必要的讀寫硬體，會排擠到真正有需要的程式運行
- Interupt
- 硬中斷: kill 硬體發出來的
- 軟中斷: 由程序執行特定指令（如系統調用）引起
- 因為只有'一個'cpu 所以假如要寫兩個並存的while loop function就必須使用context switching
- function 1) 監看開關有沒有被打開
- function 2) 開關有被打開的話用音量來控制power relay
- 兩個function以一個millisecond的速度在不斷交換(context switching)
sleep()- 可中斷 sleep
- 不可中斷 sleep
參考
- IO:
- polling io 處理程序不斷的詢問IO
- interrupt io IO結束後，發出信號將處理程序叫回來
- Demo問題排除:
- 運行的OS不同，可能會無法出現教材中的數據
Process Context-Switch vs. Thread Context-Switch
- 進程上下文切換:
- 涉及將CPU從一個進程切換到另一個進程
- 包括保存和加載整個進程狀態（寄存器、內存映射等）
- 這通常更昂貴，因為涉及更多數據
- 線程上下文切換
- 則發生在同一進程內，涉及線程之間的切換
- 由於線程共享相同的內存空間，切換較輕量且更快
- 主要涉及CPU寄存器和堆棧指針
Context-Switch vs. System Call
- 上下文切換
- 是將CPU從一個任務（進程或線程）切換到另一個任務，以確保多任務處理。
- 它涉及保存當前任務的狀態並加載下一個任務的狀態。
- 系統調用
- 是程序向操作系統發出請求以執行特定操作（如文件I/O、進程控制等）。
- 它涉及從用戶模式切換到內核模式，執行請求的操作，然後返回到用戶模式。
Arduino Project Demo
CPU 100%孰劣分析?
- 切入點:運行哪種OS
- 看使用者狀況，使用者不反應越高越好。
- 32 core 時不超過，應為ps會waiting，高併發的情況下會越來越嚴重。
- DB cpu不能吃太高(30%就會IO BONUD)
- 雲端吃到爆/地端需要注意
- 應用程式場景不同考量不同
問題與討論
- 單一台機器的效能與多機器（服務）效能的分析，有什麼共通性？
- 資源利用率：無論是單一機器還是多機器，資源（如CPU、RAM、存儲等）的利用率都是效能分析的重要指標
- 高效的資源利用可以提高整體效能
- 響應時間：無論是單一機器還是多機器系統，響應時間越短，效能越好
- 吞吐量: 系統在單位時間內能夠處理的請求數量
- 高吞吐量 == 更高的效能
- 可擴展性：即在增加負載時，系統能否保持良好的效能
- 垂直(Scale up): 提升單機的硬體&架構性能
- 水平(Scale out): 增加多台機器數量
- 故障恢復能力：無論是單一機器還是多機器系統，系統能夠快速恢復並繼續運行，對於保持高效能至關重要
- 資源利用率：無論是單一機器還是多機器，資源（如CPU、RAM、存儲等）的利用率都是效能分析的重要指標
