auto_trade_sys/docs/common/单账号内存评估与Redis减压.md

单账号交易服务内存评估与 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 承担。