# 内存问题排查与优化指南

## 问题症状

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

## 快速诊断

运行内存诊断脚本：
```bash
cd backend
./检查内存问题.sh
```

## 已做的优化（本次）

### 1. K 线缓存清理机制

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

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

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

## 临时解决方案

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

```bash
# 通过 supervisor
supervisorctl restart auto_sys_*

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

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

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

在配置中设置：
```json
{
  "SCAN_MAX_SYMBOLS": 20
}
```

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

### 方法 3：降低扫描频率

```json
{
  "SCAN_INTERVAL_SEC": 600
}
```

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

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

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

在配置中设置：
```json
{
  "USE_SHARED_MARKET_WS": false
}
```

## 长期优化建议

### 1. 监控内存使用

定期检查交易服务进程的内存占用：
```bash
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. **定期检查**：每周运行一次内存诊断脚本