auto_trade_sys/docs/负载问题排查与降负载.md

负载问题排查与快速降负载指南

当前负载：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（历史较低）

快速诊断

运行诊断脚本：

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 密集操作。

检查方法：

# 查看交易服务日志
tail -f trading_system/logs/trading_*.log | grep -i "扫描\|scan"

临时降负载： 在配置中设置 SCAN_ENABLED=False 暂停扫描（但会停止策略交易）

3. 多个账号进程同时运行

如果有多个账号，每个账号一个进程，且同时开始扫描，负载会叠加。

检查方法：

ps aux | grep "python.*trading\|python.*main" | grep -v grep

优化：

• 确保 SCAN_CONCURRENT_SYMBOLS=2（2 CPU 4G 多账号建议 2）
• 如果仍高，可降为 1

4. 数据库查询慢

虽然已优化了订单列表查询，但同步操作仍可能产生大量查询。

检查方法：

# 如果有 MySQL 慢查询日志
tail -f /var/log/mysql/slow.log

快速降负载方法

方法 1：等待同步完成（推荐）

如果正在同步订单，等待完成是最安全的做法。同步完成后负载会自动降下来。

方法 2：降低扫描并发

在配置中设置：

{
  "SCAN_CONCURRENT_SYMBOLS": 1
}

这会降低市场扫描的 CPU 占用，但扫描时间会变长。

方法 3：暂停市场扫描（临时）

在配置中设置：

{
  "SCAN_ENABLED": false
}

注意：这会停止策略交易，只在紧急降负载时使用。

方法 4：重启交易服务（最后手段）

如果进程异常或卡死：

# 通过 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 属于偏高，需要排查原因。