在 CentOS 上对 DolphinDB 进行性能测试
一 环境准备与基线
- 明确被测对象与版本：DolphinDB 单机或集群、操作系统为 CentOS 7/8、CPU/内存/磁盘/网络规格、部署拓扑（副本数、数据节点数）。建议固定内核与启动参数，避免测试过程变更。
- 校准基础环境：
- 关闭透明大页（THP）：echo never > /sys/kernel/mm/transparent_hugepage/enabled；echo never > /sys/kernel/mm/transparent_hugepage/defrag
- 设置磁盘调度为 deadline/noop：echo deadline > /sys/block/sdX/queue/scheduler
- 预留内存与文件句柄：ulimit -n 65536；vm.swappiness=1
- 检查 glibc 版本：ldd --version；若版本低于 2.23 且为高并发跨分区查询场景，后续可评估升级或使用 rpath 绑定高版本 glibc 的优化路径。
- 基线采集：记录磁盘 iostat、网络 sar、CPU mpstat、内存 free 等，确保测试过程资源稳定。
二 测试类型与指标
- 吞吐与延迟：
- 数据写入吞吐（records/s、MB/s）、查询 P50/P95/P99 延迟、并发查询下吞吐变化。
- 资源与稳定性：
- CPU 利用率、磁盘 IO 利用率与延迟、网络吞吐、JVM/进程常驻内存、错误与超时率。
- 典型场景：
- 批量导入（TSDB/OLAP 引擎）、点查/范围查询、聚合与排序、并发压力、流计算端到端延迟与吞吐。
- 结果记录建议：统一表格记录“场景-数据量-并发-配置-指标”，并保留日志与系统监控图，便于复现与回溯。
三 快速上手 内置 Mock 数据生成与基准测试
- 准备：DolphinDB 2.00.13+，将 MockData.dos 放入节点的 [home]/modules 目录，使用 use MockData 导入。
- 生成模拟数据：
- 单日 Level-2 快照：t = stockSnapshot(tradeDate=2020.01.06, securityNumber=10)（单日单标约 4,802 行）。
- 逐笔委托：stockEntrust(tradeDate, securityNumber)（单日单标约 28,802 行）。
- 逐笔成交：stockTrade(tradeDate, securityNumber)（单日单标约 28,802 行）。
- 期货 500ms 因子：futuresFactor(startDate, endDate, securityNumber, factorNumber)（如 50 标×10 因子、周期 2021-12-15~2021-12-31，变量约 10.6GB）。
- 建库建表与写入基准：
- 快照库表：t = stockSnapShotPT(“dfs://merge_TB”, “merge_snapshotTB”)；t.append!(snapshotData)
- 因子库表：t = futuresFactorPT(“dfs://futuresFactorDB”, “futuresFactorTB”)；t.append!(futuresFactorData)
- 查询与并发：基于上述库表设计点查、范围查询、分组聚合、TopN 等 SQL/脚本，使用脚本或压测工具逐步提升并发，记录 P95/P99 延迟与吞吐。
- 说明：Mock 数据仅用于性能与功能体验，不具备业务含义。
四 真实业务场景与流计算测试
- 批量导入与查询：以实际业务 schema 与分区策略（如按日期、按标的 HASH）生成/导入数据，执行典型 SQL（过滤、分组聚合、排序、窗口），记录导入速率与查询延迟。
- 并发压力：使用多客户端或多线程脚本，从 1/5/10/20/50/100 并发阶梯加压，观察吞吐拐点与错误率。
- 流计算端到端：以 Kafka + DolphinDB 流引擎 计算分钟 K 线为例，评估从消费到落库的整体吞吐与延迟。示例要点：
- 创建时间序列引擎：windowSize=60000, step=60000，metrics 为 first/open/max/min/last/wavg。
- 订阅 Kafka，batchSize=1000, throttle=1，按系统时间切片。
- 记录不同数据量（如 100 万/500 万/1000 万 条）下的耗时、RPS（records/s）与吞吐（MB/s），多次取平均。
五 常见问题与优化建议
- glibc 版本瓶颈：在 高并发、跨多分区 查询下，glibc 低于 2.23 时 fseek 可能成为热点，导致查询堆积但 CPU 利用率不高。可通过编译高版本 glibc 并使用 patchelf 调整可执行文件与动态库 rpath，在不升级系统的前提下获得明显加速；修改后用 ldd 验证库路径。实测在 DolphinDB 2.00.9.3 的对比中，并发查询从 1.61× 到 4.79× 不等（如 100 并发由 224,902 ms 降至 46,938 ms）。
- 集群负载均衡：扩容或新增磁盘后，需进行 数据迁移与再平衡，避免数据/IO 倾斜导致部分节点/磁盘过载，影响访问延迟与吞吐。
- 结果复现：固定 DolphinDB 配置（如 workerNum、TSDBCacheEngineSize、内存上限）、数据分布与分区键、并发模型与查询脚本，保留监控与日志，便于横向/纵向对比。
