---
# System prepended metadata

title: 'SRE 讀書會 Round 4 #01 - 線上讀書會共筆'
tags: [Linux, SRE]

---

---
title: [SRE 讀書會] Round 4 線上讀書會共筆-01
tags: "Linux", "SRE"
---

## 活動資訊 

* Date: 2020/04/23 (四) 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)


## Slides

* 01 | 如何學習Linux性能優化？ - Rick
* 02 | 基礎篇:到底應該怎麼理解“平均負載”? -  阿福
* 03 | 基礎篇：經常說的 CPU 上下文切換是什麼意思？（上） - 阿瑋
* 04 | 基礎篇：經常說的 CPU 上下文切換是什麼意思？（下） - 阿瑋


## 現場共筆 

### 如何快速入門
- 技巧一：雖然系統的原理很重要，但在剛開始一定不要試圖抓住所有的實現細節
    - 不需要瞭解
      * 每個元件的所有實現細節
      * 每個人的所有心裡的想法
    - 只要能理解
      * 最基本的工作原理&特性
          * 瞭解 Linux 常用命令的使用方法
          * 知道怎麼安裝和管理軟件包
          * 知道怎麼通過程式編程語言開發應用程序等
      * 協作方式
- 技巧二：邊學邊實踐，通過大量的案例演習掌握 Linux 性能的分析和優化
    - 進行大量的實戰練習，建立起整體效能的全局觀
    - 實做>理論
- 技巧三：勤思考，多反思，善總結，多問為什麼

### 效能
#### 指標
- 應用負載: 直接影響了產品終端的用戶體驗 (End User)
  * 高並發 (High Concurrency): 系統能是否同時處理大量用戶發出請求的能力
  * 響應快 (Quick Response)
- 系統資源: 資源使用率、飽和度
  * 吞吐量 (Througtput): 時間內可處理的請求數量
  * 延遲時間 (Latency)

#### 分析流程
1. 選擇指標，評估應用程式和系統效能 → SLI (Service Level Indicator)
2. 為應用程式和系統設置效能目標 → SLO (Service Level Objective)
3. 進行效能基準測試 → Benchmark、Capacity
     a. [如何量測系統的容量？（壓力測試）](https://rickhw.github.io/2019/09/20/SQA/How-to-Measure-System-Capacity/)
4. 效能分析定位瓶頸 → Bottlebeck
     a. [系統發生異常時，第一時間如何快速止血？](https://rickhw.github.io/2019/10/04/DevOps/How-to-Figure-out-the-RootCause-for-an-AbnormalSystem-In-ZeroTime/)
5. 改善 (優化) 系統和應用程式 → 重構
6. 效能監控和告警

### 系統平均負載
- 代表一段時間內的系統工作量
  - 影響因素
      * 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)
- uptime(htop) 比起第一個數據，更要注意第二、三數據 
- Zabbix 的監測結果跟 "top/uptime" 沒有一致
    - 因為不同軟體的實作方式都有差異
    - 實際上 Zabbix 採用的是讀取 `/proc/stat` 來進行計算
      * 相關的內容在 [zabbix](https://github.com/zabbix/zabbix/blob/master/src/zabbix_agent/cpustat.c#L371)
- [fio](https://github.com/axboe/fio) 此工具可以針對不同的寫 block 的方式做壓測
- buffer的地方滿多的
    - 從 library -> kernel -> disk 三層都有
    - 有興趣的可以閱讀這篇文章 [Ensuring data reaches disk](https://lwn.net/Articles/457667/)
    - 在書本裡面的範例出現的問題應該是在 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 
  1. 硬中斷: kill 硬體發出來的
  2. 軟中斷: 由程序執行特定指令（如系統調用）引起 
- 因為只有'一個'cpu 所以假如要寫兩個並存的while loop function就必須使用context switching
  * function 1) 監看開關有沒有被打開 
  * function 2) 開關有被打開的話用音量來控制power relay
- 兩個function以一個millisecond的速度在不斷交換(context switching) 
- `sleep()`
    1. 可中斷 sleep
    2. 不可中斷 sleep
    [參考](https://www.oreilly.com/library/view/linux-device-drivers/0596000081/ch05s02.html)
- IO:
    1. polling io 處理程序不斷的詢問IO
    2. 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
- 阿光 單core 
  - [Code](https://github.com/antigenius0910/lightbulb_drumtrigger/blob/master/Drum_trigger_light_bulbs.ino#L40~L59)
  - [project影片](https://www.facebook.com/yenkuang.chuang/videos/a.10213879098592069/10213879098712072/?type=3)

### CPU 100%孰劣分析?

1. 切入點:運行哪種OS
2. 看使用者狀況，使用者不反應越高越好。
3. 32 core 時不超過，應為ps會waiting，高併發的情況下會越來越嚴重。
4. DB cpu不能吃太高(30%就會IO BONUD)
5. 雲端吃到爆/地端需要注意
6. 應用程式場景不同考量不同

### 問題與討論
- 單一台機器的效能與多機器（服務）效能的分析，有什麼共通性？
  * 資源利用率：無論是單一機器還是多機器，資源（如CPU、RAM、存儲等）的利用率都是效能分析的重要指標
      * 高效的資源利用可以提高整體效能
  * 響應時間：無論是單一機器還是多機器系統，響應時間越短，效能越好
  * 吞吐量: 系統在單位時間內能夠處理的請求數量
      * 高吞吐量 == 更高的效能
  * 可擴展性：即在增加負載時，系統能否保持良好的效能
      * 垂直(Scale up): 提升單機的硬體&架構性能
      * 水平(Scale out): 增加多台機器數量
  * 故障恢復能力：無論是單一機器還是多機器系統，系統能夠快速恢復並繼續運行，對於保持高效能至關重要
  

## 參考資料
- [ Operating Systems: Three Easy Pieces](http://pages.cs.wisc.edu/~remzi/OSTEP/)
- https://store.steampowered.com/app/504210/SHENZHEN_IO/
