cbb943dfe5
Trace pipeline pool isolation: - Switch event_fetcher and lineage_engine to read_sql_df_slow (non-pooled) - Reduce EVENT_FETCHER_MAX_WORKERS 4→2, TRACE_EVENTS_MAX_WORKERS 4→2 - Add 60s timeout per batch query, cache skip for CID>10K - Early del raw_domain_results + gc.collect() for large queries - Increase DB_SLOW_MAX_CONCURRENT: base 3→5, dev 2→3, prod 3→5 Test fixes (51 pre-existing failures → 0): - reject_history: WORKFLOW CSV header, strict bool validation, pareto mock path - portal shell: remove non-existent /tmtt-defect route from tests - conftest: add --run-stress option to skip stress/load tests by default - migration tests: skipif baseline directory missing - performance test: update Vite asset assertion - wip hold: add firstname/waferdesc mock params - template integration: add /reject-history canonical route Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
3.5 KiB
Context
MSD trace pipeline 有三個階段：seed-resolve → lineage → events。
seed-resolve 已使用 read_sql_df_slow（獨立連線），但 lineage 和 events 仍用
read_sql_df（pool 連線，55s timeout）。大範圍查詢（114K CIDs）的 events 階段會
產生 ~230 條 Oracle 查詢，佔滿 pool（10+15=25 connections），導致背景任務和其他
worker 拿不到連線，最終 cascade failure（Redis timeout → worker SIGKILL）。
Connection pool 設計用於即時監控頁的短暫查詢（<1s），不適合 trace pipeline 的長時間批次作業。
Goals / Non-Goals
Goals:
- trace pipeline（lineage + events）的 Oracle 查詢不佔用共用 pool
- 降低同時 Oracle 查詢數，減少 DB 壓力
- 大查詢（>10K CIDs）不觸發 Redis/L1 cache 寫入，避免 OOM 和 Redis timeout
- 背景任務（equipment cache、SYS_DATE）在 trace 執行期間可正常取得 pool 連線
Non-Goals:
- 加入 CID 數量上限（會導致資料不完整）
- 重構 event_fetcher 為 streaming/chunk 架構（未來改善）
- 修改前端 timeout 或即時監控頁
Decisions
D1: event_fetcher + lineage_engine 改用 read_sql_df_slow
選擇: import alias 切換 (read_sql_df_slow as read_sql_df)
理由: 最小改動量。所有 call site 不需修改，只改 import 行。read_sql_df_slow
建立獨立 oracledb 連線，不佔用 pool。
替代方案考慮:
- 建立第二個專用 pool → 過度工程，管理複雜
- 給 event_fetcher 自己的 semaphore → 增加兩套 semaphore 的管理複雜度
D2: 降低 workers 預設值
選擇:
EVENT_FETCHER_MAX_WORKERS: 4 → 2TRACE_EVENTS_MAX_WORKERS: 4 → 2
理由: Peak concurrent = 2 domains × 2 workers = 4 slow queries。 搭配 semaphore=5 留 1 slot 給其他 slow 查詢。仍可透過 env var 調整。
D3: event_fetcher 批次查詢 timeout = 60s
選擇: 在 _fetch_batch 傳入 timeout_seconds=60
理由: 每個 batch query 正常 2-6s，300s 預設過長。60s 是 10x headroom。 lineage 不設限（CONNECT BY 可能較慢，保留 300s 預設）。
D4: 大 CID 集跳過快取（threshold = 10K）
選擇: CACHE_SKIP_CID_THRESHOLD = 10000（env var 可調）
理由:
- 114K CIDs 的 cache key 是 sorted CIDs 的 MD5，同組查詢再次命中機率極低
- JSON 序列化 1M+ records 可達數百 MB，Redis
socket_timeout=5s必定 timeout - L1 MemoryTTLCache 會在 heap 留住 GB 級 dict 達 TTL(300s)
route-level events cache 同樣在 CID > 10K 時跳過。
D5: 早期記憶體釋放 + gc.collect
選擇: trace_routes events endpoint 在 MSD aggregation 後 del raw_domain_results，
大查詢後 gc.collect()。
理由: raw_domain_results 和 results 是同份資料的兩種 representation，
aggregation 完成後 grouped-by-CID 版本不再需要。gc.collect() 確保
Python 的 generational GC 及時回收大量 dict。
Risks / Trade-offs
| 風險 | 緩解 |
|---|---|
| lineage 70K lots → 70+ sequential slow queries (~140s) 可能逼近 360s timeout | 已有 Redis cache TTL=300s，重複查詢走快取。首次最壞情況 ~280s < 360s |
| semaphore=5 在多個大查詢同時執行時可能排隊 | 每條 batch query 2-6s，排隊等待 <10s（wait timeout=60s 足夠） |
| 跳過 cache 後重複大查詢需重新執行 | 大查詢本身罕見（需 5 月範圍 + 特定站點），不值得佔用 cache 空間 |
gc.collect() 有微小 CPU 開銷 |
僅在 CID>10K 時觸發，且在 response 建構後執行 |