Some checks failed
CD Pipeline / deploy (push) Failing after 59s
- 建立 Gitea Actions CD pipeline (.gitea/workflows/cd.yaml) - 部署模式: rsync Python 檔案至 188 → docker restart (volume mount) - Dockerfile/requirements 變動時自動重建 Docker image - 部署通知: Telegram (開始/成功/失敗) - 健康檢查: https://mo.wooo.work/health (最多 5 次重試) - 同步最新 CLAUDE.md / ADR-008 / memory (2026-04-19) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
5.3 KiB
5.3 KiB
爬蟲資源消耗分析與優化方案
分析日期:2026-01-14 問題:爬蟲消耗過高 CPU 資源(單個 Chrome 程序可達 50%+ CPU)
🔍 問題分析
當前配置(scheduler.py)
# Chrome Options 配置
options.add_argument('--headless=new')
options.add_argument('--disable-gpu')
options.add_argument('--no-sandbox')
options.add_argument('--disable-dev-shm-usage')
options.add_argument('--force-device-scale-factor=3') # ⚠️ 3倍解析度
options.add_argument('--lang=zh-TW')
options.add_argument('--high-dpi-support=1')
資源消耗分析
| 配置項目 | 作用 | CPU 影響 | 記憶體影響 |
|---|---|---|---|
--headless=new |
無頭模式 | 低 | 低 |
--disable-gpu |
禁用GPU | 中(CPU渲染) | 低 |
--no-sandbox |
禁用沙盒 | 低 | 低 |
--force-device-scale-factor=3 |
3倍解析度 | 極高 | 高 |
--high-dpi-support=1 |
高DPI支援 | 中 | 中 |
關鍵問題
-
3倍解析度(
scale-factor=3):- 渲染面積增加 9 倍(3×3)
- Chrome 需要渲染
5760×15000像素(原本1920×5000) - 單個頁面渲染可消耗 50%+ CPU
-
無GPU加速(
--disable-gpu):- 所有渲染由 CPU 執行
- 配合 3 倍解析度,CPU 負擔極重
-
缺少資源限制:
- 無並發限制
- 無單進程模式
- 無記憶體限制
🎯 優化方案
方案 A:最小化資源消耗(推薦)
適用場景:不需要高清截圖,只需要抓取商品資料
修改項目:
# 1. 降低解析度倍數:3 → 1
options.add_argument('--force-device-scale-factor=1') # 從 3 改為 1
# 2. 使用單進程模式(減少 Chrome 子程序)
options.add_argument('--single-process')
# 3. 禁用軟體光柵化器
options.add_argument('--disable-software-rasterizer')
# 4. 限制記憶體使用
options.add_argument('--max-old-space-size=512')
預期效果:
- CPU 使用:降低 70-80%(50% → 10%)
- 記憶體使用:降低 60%(500MB → 200MB)
- 頁面載入速度:提升 50%
方案 B:平衡效能(需要截圖但降低負擔)
適用場景:需要截圖功能,但可以接受較低解析度
修改項目:
# 1. 降低解析度倍數:3 → 1.5
options.add_argument('--force-device-scale-factor=1.5') # 從 3 改為 1.5
# 2. 啟用 GPU 加速(讓 GPU 分擔渲染)
# options.add_argument('--disable-gpu') # 註解掉此行
options.add_argument('--enable-gpu-rasterization')
# 3. 使用單進程模式
options.add_argument('--single-process')
預期效果:
- CPU 使用:降低 50-60%(50% → 20%)
- 記憶體使用:降低 40%(500MB → 300MB)
- 截圖品質:仍然清晰(1.5倍解析度足夠)
方案 C:降低執行頻率
當前配置:每小時執行 3 個爬蟲(商品看板、EDM、購物節)
優化建議:
# run_scheduler.py 修改執行頻率
schedule.every(4).hours.do(run_momo_task) # 每 1 小時 → 每 4 小時
schedule.every(4).hours.do(run_edm_task) # 每 1 小時 → 每 4 小時
schedule.every(6).hours.do(run_festival_task) # 每 1 小時 → 每 6 小時
預期效果:
- 平均 CPU 使用:降低 75%
- 爬蟲執行次數:從 24次/天 → 6次/天
方案 D:使用輕量級替代方案
完全移除 Selenium,改用:
requests+BeautifulSoup(如果網站允許)httpx+parsel(更快的 HTTP 客戶端)playwright(比 Selenium 更輕量)
優缺點:
- ✅ CPU 使用降低 90%+
- ❌ 需要重寫爬蟲代碼
- ❌ 可能無法處理 JavaScript 渲染的網站
📊 建議實施順序
第一階段:立即優化(方案 A + 方案 C)
-
修改 scheduler.py:
- 降低解析度:
scale-factor=3→scale-factor=1 - 增加
--single-process - 增加
--disable-software-rasterizer
- 降低解析度:
-
降低執行頻率:
- 商品看板:每 4 小時
- EDM爬蟲:每 4 小時
- 購物節:每 6 小時
預期結果:
- 資源消耗降低 80-85%
- 仍能維持基本監控需求
第二階段:評估效果(1-2 天後)
- 檢查 Grafana 監控數據
- 確認爬蟲是否正常運作
- 評估是否需要進一步優化
第三階段:長期優化(可選)
- 考慮改用 Playwright(輕量級)
- 實施任務隊列(Celery)
- 分離爬蟲到獨立 VM(如需高頻率爬蟲)
⚠️ 重要提醒
截圖功能影響
如果您的通知系統需要高清截圖(force-device-scale-factor=3),請選擇方案 B(1.5倍解析度)。
如果不需要高清截圖,建議選擇方案 A(1倍解析度),可大幅降低資源消耗。
Systemd 服務
目前 momo-scheduler.service 已停用。如果需要重新啟動:
sudo systemctl start momo-scheduler # 啟動
sudo systemctl enable momo-scheduler # 設為開機自啟動
建議:優化完成後再啟動服務。
🔧 實施腳本
我已準備好優化後的代碼,請確認要使用哪個方案:
- 方案 A(推薦):最大化降低資源消耗
- 方案 B:平衡效能與截圖品質
- 方案 C:僅降低執行頻率
文件版本:1.0 最後更新:2026-01-14 維護人員:MOMO Pro System Admin