Yoru Karu Studio
程式設計學習筆記 | 生活心得程式設計學習筆記 | 生活心得
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，記憶體會被釋放但在某些情況下，記憶體無法被正確釋放：
「FATAL: sorry, too many clients already」— 這個錯誤通常意味著發生了連接洩漏。什麼是連接洩漏？如何快速定位洩漏源頭？如何預防？
本文將提供完整的連接洩漏排查流程，從發現症狀到根治問題，並分享生產環境的預防策略。
04-1. Worker 超時問題 Worker 超時是 Gunicorn 生產環境中最常見的問題之一。本章將深入探討超時的成因、診斷方法與解決方案。
1. 什麼是 Worker 超時？ 超時機制 Gunicorn 使用 主進程監控機制 來管理 Worker：
# Gunicorn 的超時檢查機制（簡化版） class Arbiter: def murder_workers(self): """主進程定期檢查 Worker 是否超時""" now = time.time() for worker_pid, worker in self.workers.items(): if (now - worker.last_notif) > self.timeout: # Worker 在 timeout 秒內沒有回應 os.kill(worker_pid, signal.SIGKILL) # 強制殺死 self.log.critical("Worker %s timeout, killed", worker_pid)預設超時時間 # gunicorn.conf.py timeout = 30 # 預設 30 秒 # 超時後會發生什麼： # 1. 主進程發現 Worker 超過 30 秒沒有回應 # 2.