13a0e7d580
删除了多个不再使用的文档和代码文件，包括交易更新推送、条件订单推送、REST API 文档、WebSocket API 文档及相关的策略分析文档。这些文件的移除有助于清理代码库，确保项目的整洁性与可维护性。
130 lines
3.4 KiB
Markdown
130 lines
3.4 KiB
Markdown
# 内存问题排查与优化指南
|
||
|
||
## 问题症状
|
||
|
||
- **交易服务启动后卡死**
|
||
- **内存占用过高**：交易服务进程占用 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. **定期检查**：每周运行一次内存诊断脚本
|