删除了多个不再使用的文档和代码文件,包括交易更新推送、条件订单推送、REST API 文档、WebSocket API 文档及相关的策略分析文档。这些文件的移除有助于清理代码库,确保项目的整洁性与可维护性。
36 lines
2.7 KiB
Markdown
36 lines
2.7 KiB
Markdown
# 单账号交易服务内存评估与 Redis 减压
|
||
|
||
## 1. 单账号合理内存区间
|
||
|
||
| 组成部分 | 预估范围 | 说明 |
|
||
|----------|----------|------|
|
||
| Python 解释器 + asyncio | 50–80 MB | 进程基础 |
|
||
| aiohttp + WebSocket 连接 x4 | 20–50 MB | UserData / K线 / Ticker24h / BookTicker |
|
||
| Redis 客户端连接与缓冲 | 5–15 MB | 远端 Valkey |
|
||
| 各模块小缓存(有上限) | 5–20 MB | 价格、symbol_info、持仓等,已限制条数 |
|
||
| 策略/扫描/持仓状态 | 10–30 MB | active_positions、top_symbols 等 |
|
||
| 分配器碎片、未归还 OS | 50–150 MB | Python 常见 |
|
||
| **合计(合理区间)** | **250–400 MB** | 单账号、设计正常时 |
|
||
|
||
结论:单账号**约 250–400 MB** 属正常;**500 MB 偏上**但尚可接受;若持续升到 700 MB+ 则偏异常。
|
||
|
||
你当前「多了约 500 MB」:无服务约 720 MB,开服务约 1223 MB → 交易进程约 **500 MB**,处于偏上、可接受范围。目标是通过 Redis 把压力放到远端,把进程压到 **300 MB 左右** 并稳定。
|
||
|
||
## 2. 当前仍占进程内存的来源
|
||
|
||
- **Ticker24h / BookTicker**:refresh 循环每 2 秒从 Redis 拉全量(最多 500 条)回进程,进程内常驻一份完整拷贝(约 200+ 条 × 若干 KB),是主要可优化点。
|
||
- **K 线**:Leader 已只写 Redis,进程内仅少量元数据和待写队列,占比已较小。
|
||
- **持仓/余额**:有 Redis 时只写 Redis,进程内几乎不保留。
|
||
- **价格 / symbol_info**:有 Redis 时仅降级写,条数有上限,占比小。
|
||
|
||
因此,**把 Ticker24h/BookTicker 改为“只从 Redis 按需读、进程内不再保留全量回填”**,是当前最有效的 Redis 减压手段。
|
||
|
||
## 3. 已实现:Ticker24h/BookTicker 完全用 Redis,进程内不保留全量
|
||
|
||
- **写**:Leader 不变,WS 收到后只写 Redis,并写入 `market:ticker_24h:updated_at` / `market:book_ticker:updated_at`(时间戳,供 refresh 判断是否新鲜)。
|
||
- **读**:
|
||
- **Ticker24h**:`get_tickers_24h_from_redis(redis_cache)`,由 market_scanner 在 `is_ticker_24h_cache_fresh()` 为 True 时 `await` 调用,数据全部来自 Redis。
|
||
- **BookTicker**:`get_book_ticker_from_redis(redis_cache, symbol)`,由 position_manager、binance_client 在有 redis_cache 时 `await` 调用。
|
||
- **refresh 循环**:只从 Redis 读取 `updated_at` 并写回 `_ticker_24h_updated_at` / `_book_ticker_updated_at`,**不再**拉全量数据,进程内 `_ticker_24h_cache` / `_book_ticker_cache` 在有 Redis 时保持为空。
|
||
- **进程内**:不再保留 200~500 条 ticker/book_ticker,单账号进程内存预计可再降约 50~150MB,稳定在约 **300~400MB**,压力由远端 Redis 承担。
|