auto_trade_sys/docs/common/内存问题排查与优化.md

内存问题排查与优化指南

问题症状

• 交易服务启动后卡死
• 内存占用过高：交易服务进程占用 55%+ 内存（2.1GB+）
• 系统可用内存不足：只剩 1GB 左右

快速诊断

运行内存诊断脚本：

cd backend
./检查内存问题.sh

已做的优化（本次）

1. K 线缓存清理机制

问题：_kline_cache 全局字典会无限增长，每个 symbol 的 K 线数据一直保留在内存中。

优化：

• 添加缓存大小限制：最多保留 200 个 (symbol, interval) 的缓存
• 定期清理：每 5 分钟清理一次过期缓存（超过 10 分钟未更新的）
• 自动触发：当缓存达到 80% 容量时立即清理
• 优先清理：按更新时间排序，保留最新的，清理最旧的

效果：防止 K 线缓存无限增长，减少内存占用。

临时解决方案

方法 1：重启交易服务（立即生效）

# 通过 supervisor
supervisorctl restart auto_sys_*

# 或手动
pkill -f "python.*trading_system.main"
# 然后重新启动

注意：重启会释放内存，但问题可能再次出现。

方法 2：减少扫描的交易对数量

在配置中设置：

{
  "SCAN_MAX_SYMBOLS": 20
}

限制每次扫描最多分析 20 个交易对，减少 K 线缓存占用。

方法 3：降低扫描频率

{
  "SCAN_INTERVAL_SEC": 600
}

将扫描间隔从默认值增加到 10 分钟，减少缓存更新频率。

方法 4：禁用 K 线 WebSocket（使用 REST）

如果内存问题持续，可以禁用 K 线 WebSocket，改用 REST API（但会增加 API 调用频率）：

在配置中设置：

{
  "USE_SHARED_MARKET_WS": false
}

长期优化建议

1. 监控内存使用

定期检查交易服务进程的内存占用：

ps aux | grep "trading_system.main" | awk '{print "PID:", $2, "MEM:", $4"%", "RSS:", $6/1024"MB"}'

2. 限制订阅数量

确保 SCAN_MAX_SYMBOLS 不要太大（建议 ≤ 30），避免订阅过多 symbol。

3. 检查其他内存占用源

除了 K 线缓存，还要检查：

• 持仓数据缓存：_position_updates_cache
• 余额缓存：_balance_updates_cache
• 数据库连接池：确保连接及时释放
• WebSocket 消息队列：避免消息堆积

4. 考虑升级服务器

如果内存问题持续且无法通过优化解决，考虑：

• 升级到 4 CPU / 8GB 服务器
• 或使用 Redis 存储 K 线缓存（而不是进程内存）

正常内存范围

对于 2 CPU 4GB 服务器：

• Backend 服务：100-200MB（正常）
• 交易服务（空闲）：300-500MB（正常）
• 交易服务（扫描中）：500-800MB（可接受）
• 交易服务（内存泄漏）：> 1.5GB（异常，需要排查）

当前 2.1GB 明显异常，需要排查。

排查步骤

1. 运行内存诊断脚本：./检查内存问题.sh
2. 查看交易服务日志：查找内存相关错误
3. 检查缓存大小：确认 K 线缓存是否过多
4. 检查订阅数量：确认是否订阅了过多 symbol
5. 检查数据库查询：确认是否有大量未释放的连接

预防措施

1. 定期重启：每天或每周重启一次交易服务，释放内存
2. 监控告警：设置内存使用率告警（> 80%）
3. 限制配置：确保 SCAN_MAX_SYMBOLS 和 SCAN_CONCURRENT_SYMBOLS 合理
4. 定期检查：每周运行一次内存诊断脚本