feat(diagnostics, documentation): 新增系统负载诊断脚本与指南

在 `backend` 目录下新增 `诊断负载.sh` 脚本,提供系统负载、CPU、内存使用情况及数据库连接数的快速诊断功能。新增文档 `负载问题排查与快速降负载指南.md`,详细说明负载诊断步骤、常见原因及解决方法,帮助用户有效管理系统负载。此改动提升了系统监控能力与用户支持。
This commit is contained in:
薇薇安 2026-02-18 23:35:09 +08:00
parent 33ac043324
commit e21014eb50
2 changed files with 229 additions and 0 deletions

90
backend/诊断负载.sh Executable file
View File

@ -0,0 +1,90 @@
#!/bin/bash
# 快速诊断系统负载问题
echo "=== 系统负载诊断工具 ==="
echo ""
# 1. 当前负载
echo "📊 当前负载情况:"
uptime
echo ""
# 2. CPU 和内存使用
echo "💻 CPU 和内存使用:"
top -bn1 | head -5
echo ""
# 3. 查看占用 CPU 最高的进程
echo "🔥 CPU 占用最高的进程(前 10"
ps aux --sort=-%cpu | head -11 | awk '{printf "%-8s %-6s %-6s %-6s %s\n", $1, $2, $3"%", $4"%", $11}'
echo ""
# 4. 查看 Python 进程(交易服务)
echo "🐍 Python 进程(交易服务):"
ps aux | grep -E "python.*trading|python.*main|uvicorn" | grep -v grep | awk '{printf "PID: %-6s CPU: %-5s MEM: %-5s CMD: %s\n", $2, $3"%", $4"%", $11" "$12" "$13" "$14}'
echo ""
# 5. 检查是否有同步操作在运行
echo "🔄 检查同步操作:"
if [ -f "logs/api.log" ]; then
echo "最近的同步日志(最后 10 行):"
tail -100 logs/api.log | grep -i "同步\|sync.*binance\|sync_trades" | tail -10 || echo " 未找到同步日志"
else
echo " 日志文件不存在"
fi
echo ""
# 6. 检查数据库连接数
echo "🗄️ 数据库连接数:"
if command -v mysql >/dev/null 2>&1; then
DB_HOST="${DB_HOST:-localhost}"
DB_USER="${DB_USER:-root}"
DB_PASS="${DB_PASS:-}"
DB_NAME="${DB_NAME:-auto_trade_sys}"
if [ -n "$DB_PASS" ]; then
mysql -h"$DB_HOST" -u"$DB_USER" -p"$DB_PASS" -e "SHOW PROCESSLIST;" 2>/dev/null | head -20 || echo " 无法连接数据库"
else
mysql -h"$DB_HOST" -u"$DB_USER" -e "SHOW PROCESSLIST;" 2>/dev/null | head -20 || echo " 无法连接数据库(需要配置 DB_PASS"
fi
else
echo " mysql 客户端未安装"
fi
echo ""
# 7. 检查内存使用详情
echo "💾 内存使用详情:"
free -h
echo ""
# 8. 检查是否有大量 I/O 等待
echo "📈 I/O 和系统状态5秒采样"
vmstat 1 5
echo ""
# 9. 检查交易服务日志中的错误
echo "⚠️ 最近的错误日志(最后 5 条):"
if [ -f "logs/api.log" ]; then
tail -200 logs/api.log | grep -i "error\|exception\|failed\|timeout" | tail -5 || echo " 未找到错误日志"
fi
if [ -f "../trading_system/logs/trading_*.log" ] 2>/dev/null; then
tail -200 ../trading_system/logs/trading_*.log 2>/dev/null | grep -i "error\|exception\|failed" | tail -5 || echo ""
fi
echo ""
echo "=== 诊断完成 ==="
echo ""
echo "💡 建议:"
echo " 1. 如果 CPU 占用高的是 Python 进程,可能是:"
echo " - 市场扫描正在运行(计算技术指标)"
echo " - 订单同步正在运行(从币安拉取大量订单)"
echo " - 数据库查询慢(检查慢查询日志)"
echo ""
echo " 2. 如果内存占用高,检查是否有内存泄漏"
echo ""
echo " 3. 如果 I/O 等待高,可能是数据库查询慢或磁盘慢"
echo ""
echo " 4. 临时降负载方法:"
echo " - 暂停市场扫描(在配置中设置 SCAN_ENABLED=False"
echo " - 等待同步操作完成(不要手动取消)"
echo " - 重启交易服务(如果进程异常)"

View File

@ -0,0 +1,139 @@
# 负载问题排查与快速降负载指南
## 当前负载1.592 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.0CPU 使用率 < 50%
- **偏高**Load average 1.0-1.5CPU 使用率 50-75%
- **过高**Load average > 1.5CPU 使用率 > 75%,需要关注)
- **满载**Load average ≥ 2.0CPU 100% 使用,有进程在等待)
当前 **1.59** 属于**偏高**,需要排查原因。