Yoru Karu Studio
程式設計學習筆記 | 生活心得程式設計學習筆記 | 生活心得
05-3. 面試技巧與答題模板 本章提供實用的面試技巧、答題模板和模擬對話，幫助你在面試中脫穎而出。
1. 答題結構：STAR 方法 什麼是 STAR 方法？ STAR 是回答行為問題的經典框架：
S - Situation （情境）：描述背景和問題 T - Task （任務）：你的職責是什麼 A - Action （行動）：你採取了什麼行動 R - Result （結果）：產生了什麼結果示例：遇到性能問題如何解決？ ❌ 糟糕的回答：
“我優化了 Worker 配置，然後性能就變好了。”
問題：
沒有背景 沒有具體數據 沒有展示思考過程 ✅ 優秀的回答（STAR）：
S - Situation（情境） “在上一家公司，我們的電商平台在促銷活動期間遇到性能瓶頸。具體表現是：
響應時間從平時的 100ms 增加到 2-3 秒 用戶投訴大量超時 服務器 CPU 使用率達到 95% 流量從平時的 500 QPS 增加到 3000 QPS” T - Task（任務） “作為後端負責人，我需要在 24 小時內解決性能問題，確保接下來 3 天的促銷活動順利進行。”
A - Action（行動） “我採取了以下行動：
05-2. 面試常見問題（進階） 本章整理 Gunicorn 相關的進階面試問題，涵蓋性能優化、問題排查、架構設計等高級主題。
1. 性能優化 Q1：如何優化 Gunicorn 的性能？請列舉 5 個以上的優化方法。 標準答案：
8 大優化方法：
1. 選擇正確的 Worker 類型 # gunicorn.conf.py # I/O 密集型 → Uvicorn Worker workers = 4 worker_class = 'uvicorn.workers.UvicornWorker' # CPU 密集型 → Sync Worker workers = 9 # (2 × CPU) + 1 worker_class = 'sync' # 混合型 → Gthread Worker workers = 4 threads = 10 worker_class = 'gthread'2. 啟用 preload_app 節省記憶體 preload_app = True # 記憶體節省 50-70% def post_fork(server, worker): # Worker Fork 後重新初始化資料庫連接 from django.
05-1. 面試常見問題（基礎） 本章整理 Gunicorn 相關的基礎面試問題，涵蓋核心概念、Worker 類型、配置參數等主題。
1. Gunicorn 基礎概念 Q1：什麼是 Gunicorn？它的作用是什麼？ 標準答案：
Gunicorn（Green Unicorn）是一個 WSGI/ASGI HTTP Server，用於在生產環境運行 Python Web 應用（如 Django、Flask）。
核心作用：
# Django 內建的開發服務器 python manage.py runserver # ❌ 只能處理一個請求，不適合生產環境 # Gunicorn 生產服務器 gunicorn myapp.wsgi:application # ✅ 多進程/多線程，適合生產環境三大功能：
進程管理：啟動多個 Worker 進程處理並發請求 負載均衡：自動分配請求到不同的 Worker 故障恢復：Worker 崩潰後自動重啟 架構：
客戶端請求 ↓ 主進程 (Master Process) ↓ Worker 1 → Django App Worker 2 → Django App Worker 3 → Django App Worker 4 → Django App延伸問題：為什麼不直接用 Django 的 runserver？
04-4. CPU 使用率過高 CPU 使用率過高會導致請求響應變慢、系統負載升高。本章將深入探討 CPU 性能問題的診斷與優化。
1. 什麼是 CPU 使用率過高？ 定義 CPU 使用率過高 通常指：
單核心 CPU 使用率 > 80%：該核心接近飽和 整體 CPU 使用率 > 70%：系統負載過高 Load Average > CPU 核心數：有任務在等待 CPU # 查看 CPU 使用率 top # 輸出： # %Cpu(s): 85.2 us, 2.3 sy, 0.0 ni, 12.5 id # ↑ 用戶空間 ↑ 系統調用 ↑ 空閒 # 或使用 htop（更直觀） htop正常 vs 異常 # ✅ 正常： # - CPU 使用率：30-60% # - Load Average：< CPU 核心數 # - 響應時間：< 100ms # ❌ 異常： # - CPU 使用率：> 80% 持續 # - Load Average：> CPU 核心數 × 1.
04-3. 連接數不足問題 連接數不足是高並發場景下常見的瓶頸。本章將深入探討資料庫連接池、文件描述符與網路連接的限制與解決方案。
1. 三種連接數問題 問題 1：資料庫連接池耗盡 # 錯誤訊息： django.db.utils.OperationalError: FATAL: sorry, too many clients already # PostgreSQL 預設最大連接數：100 # 或 django.db.utils.OperationalError: Can't connect to MySQL server; Too many connections # MySQL 預設最大連接數：151問題 2：系統文件描述符不足 # 錯誤訊息： OSError: [Errno 24] Too many open files # 或 Nginx 錯誤： 2025/01/31 16:00:00 [error] worker_rlimit_nofile is not enough問題 3：應用層連接洩漏 # 錯誤訊息： psycopg2.pool.PoolError: connection pool exhausted # 原因：連接未正確關閉，累積到上限 2. 為什麼會發生連接數不足？ 原因 1：Worker 數量 × 連接數超過限制 # 配置： # - Gunicorn workers: 8 # - 每個 worker 預設連接：1 # - 總連接數：8 × 1 = 8 ✅ 正常 # 但如果使用 Gthread： # - workers: 4 # - threads per worker: 10 # - 總連接數：4 × 10 = 40 # 如果流量大： # - 每個 thread 可能同時持有多個連接 # - 實際連接數：40 × 2 = 80 # PostgreSQL 預設最大連接：100 # 80 / 100 = 80% → 接近上限！原因 2：連接未正確關閉 # ❌ 錯誤：手動管理連接但忘記關閉 from django.
04-2. 記憶體洩漏問題 記憶體洩漏是 Django 生產環境中常見但難以察覺的問題。本章將深入探討記憶體洩漏的成因、診斷方法與解決方案。
1. 什麼是記憶體洩漏？ 定義 記憶體洩漏（Memory Leak） 是指程式分配的記憶體無法被釋放，導致可用記憶體逐漸減少。
# 記憶體洩漏的示意圖 # Worker 啟動時：100MB # 處理 1000 個請求後：500MB # 處理 2000 個請求後：900MB # 處理 3000 個請求後：1.2GB → 被系統 OOM killer 殺死Python 的記憶體管理 Python 使用 引用計數 + 垃圾回收 來管理記憶體：
import sys a = [1, 2, 3] print(sys.getrefcount(a)) # 2（a 本身 + getrefcount 參數） b = a # 引用計數 +1 print(sys.getrefcount(a)) # 3 del b # 引用計數 -1 print(sys.getrefcount(a)) # 2 # 當引用計數降到 0，記憶體會被釋放但在某些情況下，記憶體無法被正確釋放：