历史数据下载缓慢如何提高速度

一、我用CODEX写的系统，历史数据补充（每日盘后补充当日全量数据）速度很慢，有什么方法能提高速度吗？

测试结果

• 16 个独立进程、16 个独立 TqApi/wait_update。
• 每个 owner 同时只下载一个品种，完成后立即从共享队列领取下一项。
• 16 个 VP worker 同样逐项领取共享计算队列。
• 1232/1232 项下载成功，全部一次成功，无重试。
• 新旧 1232 个 CSV 的身份、字节数和 SHA-256 完全一致。
• 三个 SQLite 数据库完整性均为 ok。
• 当前所有测试进程均已退出。

阶段
单 owner
8 owner 静态
16 owner 动态

Tick
27分23秒
14分50秒
13分13秒

全历史
29分23秒
15分52秒
13分43秒

VPGrid
11分59秒
1分30秒
1分28秒

16 动态 owner 相比：

• • 单 owner：Tick 提速 2.07 倍，全历史提速 2.14 倍。
  • 8 owner：Tick 再提速 12.2%，全历史再提速 15.7%。
  • 整轮下载、VP及启动收尾总耗时：约 15分19秒。
  • 资源表现：
    • 历史下载 CPU 平均 9.0%，峰值 38.9%。
    • 下载期间最低仍有约 17.2 GB 可用内存。
    • VP CPU 平均 40.3%，峰值 48.2%。
    • VP 162 个序列成功、810 组；14 个冷门序列数据不足，与前两轮完全一致。
    • 算法失败、服务端拒绝、断线和数据库锁冲突均为 0。

    一个 owner 在整批累计订阅较多不同品种后收到一次 TqSdk“推荐批量订阅”的非致命提示。源码确认 DataDownloader 会释放 chart 资源，但 Quote 对象会在同一 TqApi 生命周期内积累。因此正式设计规定：owner 只存活一个收盘批次，完成后全部销毁，不跨交易日常驻。

    结论：16 owner 动态队列可以作为“停盘后全速补全”方案，但不适合盘中使用。相对 8 owner 的边际收益只有约 11%–16%，说明继续增加到 32 owner 的意义已不大，剩余瓶颈主要在天勤服务端或账号会话吞吐。

二、如何在盘中断线复连后快速补充逐笔tick?我的策略以来逐笔数据来计算VP分布。