内存泄露

[ElderDoge]

平均一天发生一次，内存泄露很快顶爆服务器，然后死机必须重启。有时候用一天，有时候重启10分钟就泄露。

[github-actions]

Thank you for reporting this memory leak issue.

Analysis:

Based on the screenshot showing memory usage growing from ~1800MB to ~3120MB with high utilization (avg 73.74%, max 97.787%), this is a concerning memory leak pattern. The current version (v0.8.7) already includes several memory-related fixes from recent commits:

• 1fe972b4 - cap client abort drain window (fix(proxy): cap client abort drain window #1277)
• 8968a426 - clean up client abort listeners (fix(proxy): clean up client abort listeners #1113)
• 9948c708 - harden proxy stream lifecycle to avoid SIGSEGV (fix: harden proxy stream lifecycle to avoid SIGSEGV under load (#1147) #1152)
• b0c9eaf5 - public-status Redis leak (fix: disabled-key 429 lockout, slow availability page, public-status Redis leak #1187)

Potentially relevant code areas:

1. Agent Pool (src/lib/proxy-agent/agent-pool.ts, lines 218-937)

   • Manages HTTP connection pooling with TTL-based expiration (default 5 minutes)
   • Has cleanup interval (default 30 seconds) but retired agents can accumulate
   • Includes pendingCleanups Set for tracking close operations

2. Session Cache (src/lib/cache/session-cache.ts)

   • TTLMap-based caching with LRU eviction
   • Cleanup interval defaults to 60 seconds
   • Max sizes: active sessions (100), session details (10,000)

3. Stream Handling (src/app/v1/_lib/proxy/node-stream-to-web.ts)

   • Node.js Readable to Web ReadableStream conversion
   • Has protection against double-settling (issue App exits with SIGSEGV under proxy load, causing nginx 502 bursts #1147 fix)

4. Response Handler (src/app/v1/_lib/proxy/response-handler.ts)

   • Client abort drain window: 60 seconds max (line 59: CLIENT_ABORT_DRAIN_MAX_MS)
   • Accumulates full response content in memory for usage parsing

To help diagnose this, please provide:

• What is the server memory size? (The 3120MB max suggests ~4GB total)
• What is your traffic load? (requests per minute, concurrent connections)
• Are you using streaming or non-streaming requests predominantly?
• What proxy protocols are in use? (HTTP/1.1, HTTP/2, SOCKS)
• Do you see any patterns before the crash? (specific endpoints, error logs)
• Are there any warning logs about "AgentPool", "pendingCleanups", or "drain timeout"?
• Environment variables set: SESSION_TTL, FETCH_CONNECT_TIMEOUT, MAX_TOTAL_AGENTS (if any)

Potential diagnostic steps:

1. Check agent pool stats: Look for any API endpoint or log that shows cacheSize, retiredAgents, pendingCreations metrics
2. Enable debug logging for AgentPool to track cleanup cycles
3. Monitor heap dumps if possible (Node.js --heapsnapshot-signal=SIGUSR2)

---

Automated response from Claude AI