857128bca9
在 `config.py` 中新增多账号扫描配置，支持并发数和错峰扫描设置。更新 `market_scanner.py` 以根据配置动态调整并发请求数，优化资源使用。修改 `strategy.py` 以实现多账号错峰扫描，避免低配服务器的 CPU 过载，提升系统稳定性和效率。
91 lines
4.3 KiB
Markdown
91 lines
4.3 KiB
Markdown
# 多账号与低配服务器负载优化
|
||
|
||
针对 **2 CPU / 4 GB** 等低配服务器、多账号交易进程同时运行时的 CPU 打满问题，说明主要负载来源与可调参数。
|
||
|
||
---
|
||
|
||
## 一、负载从哪里来
|
||
|
||
### 1. 每个账号 = 一个独立进程
|
||
|
||
- 每个 `ATS_ACCOUNT_ID` 一个 Python 进程（如 4 个账号 = 4 个进程）。
|
||
- 每个进程内：**市场扫描**、**持仓同步**、**User Data Stream**、若为 Leader 还有 **Ticker/K线/BookTicker WS** 及写 Redis。
|
||
|
||
### 2. CPU 最重的部分：市场扫描
|
||
|
||
- **扫描阶段**：对「初步筛选」后的几十个交易对，**并发**做「拉 K 线 + 算技术指标（RSI/MACD/布林/ATR/EMA）」。
|
||
- 指标是纯 Python 循环，**每个 symbol 算 5+ 个指标**，单次扫描就有大量计算。
|
||
- **并发度**：由 `SCAN_CONCURRENT_SYMBOLS` 控制「同时分析几个 symbol」；默认已改为 **2**（原 3）。
|
||
- **多进程叠加**：若 4 个进程**同时**开始扫描，相当于 4 × 2 = **8 路**同时在算指标，2 核很容易打满。
|
||
|
||
因此：**扫描并发**和**多账号是否同时扫**是 CPU 的两大主要来源。
|
||
|
||
### 3. 其他相对较轻的部分
|
||
|
||
| 模块 | 说明 | 负载 |
|
||
|------|------|------|
|
||
| User Data Stream | 每进程 1 个 WS，收订单/持仓/余额 | 低 |
|
||
| 市场 WS（Ticker/K线/Book） | 仅 **Leader 进程**建连接并写 Redis，其余进程只从 Redis 读 | Leader 中，其余低 |
|
||
| Redis 刷新 | 每 2 秒从 Redis 拉 Ticker/Book 到本地 | 低 |
|
||
| 持仓同步 | 每 `POSITION_SYNC_INTERVAL`（如 60s）一次 REST 同步 | 低～中（与持仓数有关） |
|
||
| 配置重载 | 每轮扫描前从 Redis 重载配置 | 低 |
|
||
| exchange_info / 行情 API | 已优先走 DB/Redis 缓存，未命中才请求 API | 中（主要在未命中时） |
|
||
|
||
---
|
||
|
||
## 二、已做的可调项（直接生效）
|
||
|
||
### 1. 扫描并发：`SCAN_CONCURRENT_SYMBOLS`
|
||
|
||
- **含义**：单进程内，**同时**分析多少个交易对（K 线 + 指标）。
|
||
- **默认**：`2`（适合 2 CPU 4G、多账号）。
|
||
- **建议**：
|
||
- 2 CPU 4G、多账号：**2**；
|
||
- 单账号或 4 CPU+：可试 **3～5**。
|
||
- **配置**：在 `trading_config` 或 `config.py` 的 `SCAN_CONCURRENT_SYMBOLS` 中设置（数字，1～10）。
|
||
|
||
### 2. 多账号错峰：`SCAN_STAGGER_BY_ACCOUNT` + `SCAN_STAGGER_SEC`
|
||
|
||
- **含义**：按 `ATS_ACCOUNT_ID` 延迟**首次**扫描开始时间，避免多进程在同一时刻一起扫。
|
||
- **默认**：`SCAN_STAGGER_BY_ACCOUNT=True`，`SCAN_STAGGER_SEC=60`。
|
||
- **效果**：例如 4 个账号，则 account 1 立即扫，2 延迟 60s，3 延迟 120s，4 延迟 180s；之后仍按各自 `SCAN_INTERVAL` 循环，自然错开。
|
||
- **配置**：
|
||
- `SCAN_STAGGER_BY_ACCOUNT`：`true`/`false`；
|
||
- `SCAN_STAGGER_SEC`：每多一个账号增加的延迟秒数（建议 60～120）。
|
||
|
||
---
|
||
|
||
## 三、还可调节的项（按需）
|
||
|
||
| 配置项 | 说明 | 建议（2 CPU 4G） |
|
||
|--------|------|------------------|
|
||
| **SCAN_INTERVAL** | 扫描间隔（秒） | 900（15 分钟）或 1800（30 分钟），减少扫描频率 |
|
||
| **MAX_SCAN_SYMBOLS** | 参与扫描的最大交易对数 | 200～300，减少进入「详细分析」的 symbol 数 |
|
||
| **MIN_CHANGE_PERCENT** / **MIN_VOLUME_24H** | 初步筛选更严 | 略提高可减少 pre_filtered 数量，从而减少指标计算量 |
|
||
| **POSITION_SYNC_INTERVAL** | 持仓同步间隔（秒） | 60 或 120，略增可减 REST 调用 |
|
||
| **同一台机账号数** | 2 CPU 4G 上跑的进程数 | 建议 ≤ 3～4；若仍卡可先跑 2 个账号 |
|
||
|
||
---
|
||
|
||
## 四、推荐组合（2 CPU 4G、多账号）
|
||
|
||
- `SCAN_CONCURRENT_SYMBOLS` = **2**
|
||
- `SCAN_STAGGER_BY_ACCOUNT` = **true**
|
||
- `SCAN_STAGGER_SEC` = **60**
|
||
- `SCAN_INTERVAL` = **900**（或 1800 若可接受更慢扫描）
|
||
- `MAX_SCAN_SYMBOLS` = **200**～**300**（可选）
|
||
|
||
若仍 CPU 偏高，可再：
|
||
|
||
- 将 `SCAN_CONCURRENT_SYMBOLS` 降为 **1**，或
|
||
- 同一台机器只跑 **2 个**账号，其余账号迁到另一台或扩容后再加。
|
||
|
||
---
|
||
|
||
## 五、如何确认是否生效
|
||
|
||
- 看日志：
|
||
- 多账号错峰：应出现类似「多账号错峰：account_id=2，延迟 60 秒后开始首次扫描」。
|
||
- 扫描并发：无单独日志，可通过「扫描耗时」和 CPU 曲线判断。
|
||
- 用 `top`/`htop` 观察：多进程同时扫描时 CPU 应比「错峰 + 并发 2」时明显更低、更平稳。
|