e21014eb50
在 `backend` 目录下新增 `诊断负载.sh` 脚本，提供系统负载、CPU、内存使用情况及数据库连接数的快速诊断功能。新增文档 `负载问题排查与快速降负载指南.md`，详细说明负载诊断步骤、常见原因及解决方法，帮助用户有效管理系统负载。此改动提升了系统监控能力与用户支持。
140 lines
3.8 KiB
Markdown
140 lines
3.8 KiB
Markdown
# 负载问题排查与快速降负载指南
|
||
|
||
## 当前负载：1.59（2 CPU 系统）
|
||
|
||
**Load average: 1.59, 0.55, 0.24** 表示：
|
||
- **1 分钟平均**：1.59（接近 2 CPU 满载，约 79.5% CPU 使用）
|
||
- **5 分钟平均**：0.55（之前较低，说明是最近才涨起来的）
|
||
- **15 分钟平均**：0.24（历史较低）
|
||
|
||
## 快速诊断
|
||
|
||
运行诊断脚本：
|
||
```bash
|
||
cd backend
|
||
./诊断负载.sh
|
||
```
|
||
|
||
这会显示：
|
||
- CPU 占用最高的进程
|
||
- Python 交易服务进程的资源占用
|
||
- 是否有同步操作在运行
|
||
- 数据库连接数
|
||
- 内存和 I/O 状态
|
||
|
||
## 常见原因
|
||
|
||
### 1. **订单同步正在运行**（最可能）
|
||
|
||
如果前端正在执行「同步订单」（特别是「全量同步 + 30 天」），会：
|
||
- 从币安拉取**所有交易对**的历史订单（可能几百个 symbol × 每个 symbol 的订单）
|
||
- 对每个订单做多次数据库查询（`get_by_exit_order_id`、`get_by_symbol` 等）
|
||
- 如果有 1000 个订单，可能产生 3000+ 次数据库查询
|
||
|
||
**解决方法**：
|
||
- **等待同步完成**（不要手动取消，否则数据可能不完整）
|
||
- 如果必须停止，可以在前端取消，但已处理的数据会保留
|
||
- 下次同步时选择**更短的时间范围**（如 7 天而不是 30 天）
|
||
- 或**不勾选「全量同步」**（只同步数据库中已有的交易对）
|
||
|
||
### 2. **市场扫描正在运行**
|
||
|
||
交易服务会定期扫描市场并计算技术指标（RSI、MACD、布林带、ATR 等），这是 CPU 密集操作。
|
||
|
||
**检查方法**：
|
||
```bash
|
||
# 查看交易服务日志
|
||
tail -f trading_system/logs/trading_*.log | grep -i "扫描\|scan"
|
||
```
|
||
|
||
**临时降负载**：
|
||
在配置中设置 `SCAN_ENABLED=False` 暂停扫描（但会停止策略交易）
|
||
|
||
### 3. **多个账号进程同时运行**
|
||
|
||
如果有多个账号，每个账号一个进程，且**同时**开始扫描，负载会叠加。
|
||
|
||
**检查方法**：
|
||
```bash
|
||
ps aux | grep "python.*trading\|python.*main" | grep -v grep
|
||
```
|
||
|
||
**优化**：
|
||
- 确保 `SCAN_CONCURRENT_SYMBOLS=2`（2 CPU 4G 多账号建议 2）
|
||
- 如果仍高，可降为 `1`
|
||
|
||
### 4. **数据库查询慢**
|
||
|
||
虽然已优化了订单列表查询，但同步操作仍可能产生大量查询。
|
||
|
||
**检查方法**：
|
||
```bash
|
||
# 如果有 MySQL 慢查询日志
|
||
tail -f /var/log/mysql/slow.log
|
||
```
|
||
|
||
## 快速降负载方法
|
||
|
||
### 方法 1：等待同步完成（推荐）
|
||
|
||
如果正在同步订单，**等待完成**是最安全的做法。同步完成后负载会自动降下来。
|
||
|
||
### 方法 2：降低扫描并发
|
||
|
||
在配置中设置：
|
||
```json
|
||
{
|
||
"SCAN_CONCURRENT_SYMBOLS": 1
|
||
}
|
||
```
|
||
|
||
这会降低市场扫描的 CPU 占用，但扫描时间会变长。
|
||
|
||
### 方法 3：暂停市场扫描（临时）
|
||
|
||
在配置中设置：
|
||
```json
|
||
{
|
||
"SCAN_ENABLED": false
|
||
}
|
||
```
|
||
|
||
**注意**：这会停止策略交易，只在紧急降负载时使用。
|
||
|
||
### 方法 4：重启交易服务（最后手段）
|
||
|
||
如果进程异常或卡死：
|
||
```bash
|
||
# 通过 supervisor
|
||
supervisorctl restart auto_sys_*
|
||
|
||
# 或手动
|
||
pkill -f "python.*trading"
|
||
# 然后重新启动
|
||
```
|
||
|
||
## 预防措施
|
||
|
||
1. **同步订单时**：
|
||
- 优先选择**较短时间范围**（7 天而不是 30 天）
|
||
- **不勾选「全量同步」**（除非确实需要补全所有交易对）
|
||
- 避免在交易高峰期同步
|
||
|
||
2. **配置优化**：
|
||
- `SCAN_CONCURRENT_SYMBOLS=2`（2 CPU 4G 多账号）
|
||
- `SCAN_INTERVAL_SEC` 不要太短（建议 ≥ 300 秒）
|
||
|
||
3. **监控**：
|
||
- 定期运行 `./诊断负载.sh` 检查系统状态
|
||
- 关注日志中的错误和警告
|
||
|
||
## 负载正常范围
|
||
|
||
对于 **2 CPU 4G** 系统：
|
||
- **正常**：Load average < 1.0（CPU 使用率 < 50%）
|
||
- **偏高**：Load average 1.0-1.5（CPU 使用率 50-75%）
|
||
- **过高**：Load average > 1.5（CPU 使用率 > 75%，需要关注）
|
||
- **满载**：Load average ≥ 2.0（CPU 100% 使用，有进程在等待）
|
||
|
||
当前 **1.59** 属于**偏高**，需要排查原因。
|