薇薇安 80872231a5 feat(kline_stream, diagnostics): 增强 K线缓存管理与系统负载诊断功能

在 `kline_stream.py` 中新增缓存清理机制，限制缓存总大小并定期清理过期条目，防止内存无限增长。更新 `backend/诊断负载.sh` 脚本，优化系统负载检查逻辑，提供更详细的进程与日志信息，提升用户对交易服务状态的监控能力。此改动增强了系统的稳定性与性能。

2026-02-19 00:06:23 +08:00

3.4 KiB

Raw Blame History

内存问题排查与优化指南

问题症状

交易服务启动后卡死
内存占用过高：交易服务进程占用 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 明显异常，需要排查。

排查步骤

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

预防措施

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

3.4 KiB Raw Blame History Unescape Escape