fix(stock-lab): snapshot flow 범위 100종목 + busy_timeout 2분 (writer 충돌 완화)
자동 잡 16:30 KST 실패 원인: - agent-office httpx timeout 180s - 그러나 snapshot/refresh의 flow 스크래핑(500종목 × 0.2-0.5s) = 100~250s - 180s 초과 시 client timeout → 서버 background 처리 계속 - 곧 /run 호출 → snapshot의 long write transaction과 INSERT 충돌 - WAL은 reader/writer 분리만, writer 두 명은 직렬 → busy_timeout 30s 초과 lock Fix: - DEFAULT_FLOW_TOP_N 500 → 100 (시총 상위 100종목 × 0.2s = ~20s) - busy_timeout 30s → 120s (snapshot write 시간보다 충분히 김) - connect timeout 30s → 120s 외국인 매수 시그널은 대형주에서 의미 큼. 상위 100종목으로 충분. 더 많은 커버리지 필요 시 별도 cron으로 snapshot/refresh와 /run 시간 분리.
This commit is contained in:
@@ -46,10 +46,11 @@ def _db_path() -> str:
|
||||
|
||||
def _conn() -> sqlite3.Connection:
|
||||
# WAL 모드 + busy_timeout으로 동시 read/write lock 회피
|
||||
# (snapshot/refresh 직후 /run이 SELECT 시 OperationalError 'database is locked' 방지)
|
||||
conn = sqlite3.connect(_db_path(), timeout=30.0)
|
||||
# WAL은 reader vs writer 동시성만 해결 — writer 두 명은 직렬이므로 busy_timeout이
|
||||
# snapshot/refresh의 write 시간보다 길어야 함 (네이버 스크래핑 ~20초 + DB upsert).
|
||||
conn = sqlite3.connect(_db_path(), timeout=120.0)
|
||||
conn.execute("PRAGMA journal_mode=WAL")
|
||||
conn.execute("PRAGMA busy_timeout=30000")
|
||||
conn.execute("PRAGMA busy_timeout=120000")
|
||||
return conn
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user