单机 · 3C3D 集群 · 双机主备 · IoTDB 1.3.7 · 可重复阶梯压测

ThingsBoard + Kafka + IoTDB
大容量性能调优手册

这不是一份“把所有线程和内存调大”的参数清单，而是一套从入口速率、Kafka offset、规则引擎完成、IoTDB写缓冲、DataNode内存和磁盘合并逐层定位瓶颈的方法。

71 / 72 / 68 / 183 四机实测全机械盘六类负载 CPU≤60% · 内存≤80% · 磁盘≤70% 更新：2026-07-28

2. 当前生产基线

后续每次容量测试都应先复制这个基线，否则无法判断优化还是回归。

已实测

消息 / 数据点

≈ 8k / 1M s⁻¹

8000 台设备，每条约 125 个 key

Kafka

50 分区 · poll 200

稳态原始 lag 约 5600–8900，为安全在途量

IoTDB 写入

flush 250ms

flushAvg 约 15–46ms，失败/背压为 0

恢复能力

≈ 168s

启动峰值约 22.9 万，5 分钟内恢复

当前的“lag 目标”应定义为：无持续积压，而不是任意时刻原始数字必须等于 0。 在持续写入且要求 IoTDB 物理 flush 成功后才提交 offset 的情况下，原始 lag 必然包含正在处理的安全在途消息。判定积压要看稳态基线、趋势和恢复旜率。

基线项	当前值	后续压测用途	不可误解
`IOTDB_WRITE_FLUSH_INTERVAL_MS`	250ms	亚秒实时基线；吞吐不足时向 500/1000ms 阶梯测试	越小不一定越快，会成倍增加 RPC
`TB_QUEUE_KAFKA_MAX_POLL_RECORDS`	200	当前满载下最小可持续值	实测 100 会因 poll/commit 频率过高而无法追平
队列分区 / 消费组	50 / 50	提供规则引擎并行度	分区数不等于吞吐；CPU、Actor、IoTDB 都要能承接
IoTDB 容器上限	96GiB	控制 DataNode 堆+堆外+原生内存	不要把 JVM 预算设成容器上限，必须留堆外和页缓存
`IOTDB_READ_POOL_SIZE`	64	读连接与写连接物理隔离	加大只会增加并发查询压力，不会自动加速查询

3. 先定位瓶颈在哪一层

参数优化的前提是知道哪一层没有余量。

MQTT / 上送端设备、消息/s、失败

Kafkalag、poll、commit、rebalance

规则引擎success、timeout、failed

IoTDB 写缓冲pending、RPC、backpressure

DataNodeflush、GC、Region、compaction

磁盘 / 查询iowait、WAL、TsFile、p95

现象	优先判定	先看什么	不要先做什么
Kafka lag 上涨，IoTDB pending 也单调上涨	IoTDB 写入速率低于入口	flushAvg/Max、RPC失败、GC、iowait、compaction 队列	只调大 Kafka poll 或 pending 上限
lag 上涨，pending 很低，IoTDB flush 很快	ThingsBoard / 规则引擎 / GC / Kafka commit	Rule Engine timeout、Actor 线程、DB callback、JVM GC、pack 耗时	调 IoTDB DataNode 内存比例
pending 周期波动但每轮回零，lag 稳定	正常攒批	将 pending 换算成“秒数”而不是看绝对值	因为看到 pending 非 0 就缩短 flush
写入正常，上查询后 lag 增长	读写资源争用	读池/写池、query timeout、DataNode 查询内存、磁盘随机读	盲目增加查询并发线程

1. IoTDB 全动态生产容量规划器

先选择单机、3C3D 集群或双机主备，再从真实上送模型推导机械盘、CPU/内存、ThingsBoard 队列和 IoTDB 参数。四机实测负责校准单节点，集群结果明确标记为推导值。

四机 HDD 实测校准 · 离线可用

0历史库与部署拓扑

本阶段只对 IoTDB 给出实测校准结果；SQL 和 Cassandra 保留入口，等对应机器压测后启用。

历史数据库未实测的数据库不会套用 IoTDB 系数部署拓扑主备容量不叠加；集群按 RF 计算写放大单节点实测校准档案计算结果会显示该档案的实测范围与局限计划 DataNode 数仅集群可调；不足时计算器会自动向上修正 CPU 规划上限（%）按单节点短稳态实测吞吐保守折算内存规划上限（%）包含 IoTDB 堆、直接内存、ConfigNode 和页缓存

1设备规模

定义同时在线设备、完整测点模型，以及变化测点是否固定。

总设备数量参与容量规划的同时在线设备总数每个设备的总点数单台设备完整遥测点位数量变化测点模式随机变化最终会激活全部序列是否使用 IoTDB 设备模板模板可显著降低 schema 压力

2变化上送

变化上送与周期全量上送分别计算，再汇总成入口稳态和峰值。

变化百分比（%）每次上送时，发生变化的点位占比变化上送频率（次/秒/设备）如每 5 秒上送 1 次，请填写 0.2 全量上送周期（秒） 300=每 5 分钟一次；0=关闭全量全量上送方式同秒全量会形成巨大瞬时峰值

3保留周期与机械盘

默认每点 12B，取自 HDD 实测约 8–17B/点的中值；规划结果另含 WAL/合并、增长与磁盘水位余量。

数据保留年限用于 IoTDB 全局 TTL 和磁盘容量实测落盘字节/点建议上线后用 24h 实际增量回填集群数据副本数（RF）仅 3C+N DataNode 集群生效；双机主备由 Pipe 保存第二份单块机械盘容量（TB）按厂商十进制容量计算数据盘保护方式全机械盘推荐数据与 WAL 分盘磁盘目标水位（%） 70% 开始扩容；禁止按 95% 算满业务增长余量（%）同时作用于吞吐和存储规划

4查询与写入目标

最新值查询主要走 LastCache；历史/聚合在机械盘上按查询范围保守拆分节点。

单 key 最新值 QPS 专项混合实测 P50≈1ms 整设备最新值 QPS 500 测点专项实测 P50≈4ms 历史/聚合查询 QPS 机械盘规划中最敏感的查询输入典型历史查询范围范围越大，HDD 随机读风险越高写缓冲 flush 窗口（ms）决定攒批效率和崩溃丢数窗口

稳态点速率 = 变化点速率 + 错峰全量点速率

长期原始盘 = 稳态点速率 × 保留秒数 × B/点 × 1.25（WAL/合并）× 增长余量 × 拓扑数据份数 ÷ 磁盘水位 ÷ RAID 可用率

单机按 1 份；集群按 RF 份且有效写入能力约为节点裸容量 ÷ RF；双机主备按 2 份但吞吐只算活动节点

IoTDB 堆 ≥ 每 100 万活跃序列 14G；规则引擎分区按 300 msg/s 或 4 万 points/s 中更严格者计算

生产容量结论

单节点实测 IoTDB 单机 CPU≤60% · 内存≤80%

规划消息速率-

规划点速率-

3 年规划原始盘-

机械盘数量-

推荐架构-

规则引擎分区-

活跃序列-

峰值点速率-

CPU-

内存-

磁盘-

A写入与存储

稳态入口负载-

每天新增点数-

每天有效落盘-

保留期逻辑数据-

规划原始盘容量-

数据盘配置-

持续/合并峰值带宽-

IoTDB 全局 TTL-

B机器与拓扑

IoTDB DataNode-

每台 DataNode CPU-

每台 DataNode 内存-

每台 IoTDB 堆预算-

ThingsBoard/规则引擎-

Kafka-

ConfigNode-

WAL 机械盘-

CThingsBoard 与队列

Main 队列分区范围-

规则引擎消费者-

max.poll.records-

每 TB 节点写分片-

每分片 pending 水位-

flush / pack timeout-

TB JVM 堆-

队列判定基线300 msg/s 或 4 万 points/s / 分区

DIoTDB 写入与查询

每节点活跃序列-

DataRegion / compaction-

内存配比-

SessionPool / 读池-

查询 CPU 预算-

HDD 查询节点下限-

设备模板-

验收测试-

E硬件选型参考

CPU 参考型号-

CPU 采购口径-

内存条组合-

内存采购要求-

数据盘参考型号-

机械盘采购要求-

阵列卡 / HBA-

机箱与备盘-

F实测依据与安全边界

证据等级-

校准机器-

邻近负载实测上限-

单节点规划安全线-

当前拓扑有效安全线-

故障一节点后-

拓扑边界-

数据日期 / 时长2026-07-13 · 300s 阶梯；长跑规则来自 ≥50min 复现

看不懂硬件型号？先看这里

型号是采购时用于确认“买的是哪一种硬盘”的完整身份；接口决定怎么连接，RAID/JBOD 决定数据怎么保护，它们不是同一个概念。

Exos / Ultrastar 是什么它们分别是希捷和西部数据的企业级机械硬盘系列，适合服务器 7×24 小时运行。它们是产品系列，不代表 SAS、SATA 或 RAID。

SAS / SATA 是什么SAS 是价格较高的服务器专用接口，故障处理和双通道能力更强；SATA 更经济、容量大。背板、线缆和控制器必须与接口匹配。

RAID10 是什么硬盘两两保存相同数据，再组合使用。坏一块盘通常还能运行，但 12×18TB 的 216TB 原始容量约只剩 108TB 可用。

JBOD 是什么每块硬盘独立交给 IoTDB，容量利用率高，但没有硬件镜像。必须依赖 IoTDB RF=2/3 和至少 3 个 DataNode 才能承受盘或节点故障。

为什么型号后缀很长例如 ST18000NM000D 与 ST18000NM003D 容量相同，但接口不同。采购单必须写完整型号、接口、扇区格式和固件要求，不能只写“18TB Exos”。

阵列卡 / HBA 是什么阵列卡负责 RAID10 和缓存保护；HBA 负责把硬盘直接交给系统。PERC H750 属于阵列卡，不是硬盘型号。

稳定优先、运维简单SAS 企业盘 + RAID10；可以防单盘损坏，但 RF=1 不能防整台服务器故障。

容量优先、成本可控SATA 企业盘 + JBOD + IoTDB RF=2；至少 3 个 DataNode，并做好坏盘更换和副本恢复演练。

不建议的组合JBOD + RF=1。没有硬件镜像也没有 IoTDB 副本，坏一块盘就可能丢数据。

四机 HDD 实测锚点71 / 72 / 68 / 183 均已记录 CPU、内存、IoTDB 堆、机械盘和六类上送负载；网页按所选机器与邻近负载取实测下限，不再只套用 71 的单一系数。

CPU 换算边界CPU 百分比按“规划复制后点速率 ÷ 所选机器邻近负载实测上限”保守换算。部分档位是“实测到此仍未到墙”，因此只代表规划尺，不是硬件厂商保证值。

长跑内存锚点按每 100 万活跃序列至少 14G 堆；短测通过不等于 1 小时和 24 小时稳定。

集群与查询边界当前集群容量按单 DataNode 实测 × 节点数 ÷ RF 推导，双机主备只完成切换与同步验收；四机全 HDD 报告未覆盖大范围混合查询，页面会明确标记“待专项压测”。

官方规格参考Intel Xeon Gold 6230 · 第五代 Xeon 选型表 · Seagate Exos X24 · WD Ultrastar HC580

查看四机全机械盘实测机器配置与六类负载原始矩阵

测试日期 2026-07-13；IoTDB 1.3.7；每设备 500 点；写缓冲 flush=1000ms；每级 300 秒 paced 浸泡。判定标准为零 overrun、零写入失败、结束 5 秒内排空。该矩阵是 DAO 写路径，不含 MQTT、规则引擎和 Kafka 全链路开销。

档案	CPU	内存	机械盘	IoTDB 堆 / 直接内存	Region / Compaction
71	2× Xeon Gold 6230；采集 160T，插槽拓扑待复核	377G	4.4T HDD 阵列 / PERC H750	64G / 12G	16 / 8
72	2× Xeon Gold 6330 / 112T	125G	9.1T HDD 阵列 / MR9560	48G / 8G	12 / 8
68	Xeon Silver 4309Y / 32T	62G	ST8000NM 8T SATA HDD 单盘	28G / 6G	8 / 4
183	Xeon Silver 4110 / 16T	30G	ST2000NM 2T HDD	10G / 2G	4 / 4

六类上送负载	71 最大可持续设备数	72	68	183
固定 30%，无全量（150 点/设备/s）	17500✅～21000❌（262万～315万点/s）	≥15000（224万）	≥9600（144万）	≥2400（36万）
随机 30%，无全量（150 点/设备/s）	≥17500（262万）	≥12600（189万）	≥8000（120万）	完整档缺失；参考约 2400
固定 20%，无全量（100 点/设备/s）	≥26000（260万）	≥19000（190万）	≥13000（130万）	≥4400（44万）
随机 20%，无全量（100 点/设备/s）	≥22000（220万）	12600✅～16500❌	9600✅～11200❌	≥3000（30万）
固定 20% + 5 分钟错峰全量（≈101.7 点/设备/s）	≥21000（213万）	≥15000（152万）	≥9600（97万）	机器失联，缺测
随机 20% + 5 分钟错峰全量（≈101.7 点/设备/s）	≥17500（177万）	12600✅～15000❌	≥9600（97万）	机器失联，缺测

读表规则：“≥”表示实测到该档仍全绿、尚未找到墙，不等于精确极限。300 秒只能证明短稳态；长期生产仍按每 100 万活跃序列至少 14G 堆，并要求 ≥1 小时干净轮和 24 小时候选水位复核。

查看单机、3C3D 集群与双机主备的证据边界

拓扑	已经证实	计算器如何计算	尚未证实
IoTDB 单机	四台 HDD 机器六类写入负载；68 全链路 60 万点/s 约 50 分钟后堆雪崩；设备模板吞吐 +25%～50%	按所选机器的邻近实测下限、CPU 水位、活跃序列堆预算和实际盘位取最小安全线	四机的大时间窗历史查询混合负载
3C + N DataNode 集群	部署配置、SessionPool 多节点路由和 IoTDB 官方副本/Region 机制；单 DataNode 参数已有实测	有效写入安全线 = 单节点安全线 × DataNode 数 ÷ RF；序列和磁盘同样乘 RF 后分摊	目标机械盘集群的满载吞吐、节点故障后的 Region 重分配、查询 P95/P99
双机主备	10.8.8.66/67 现场 VIP 切换约 0.852s / 0.714s；双向故障注入、Pipe 反向追平、180Mbit/s 限速验收通过	两端各保存完整数据、每端独立承接全部负载；容量不叠加，CPU 另加 8% 保守复制开销	目标百万点/s 满载下的 Pipe 积压、业务延迟与最终 RPO

禁止混用：3C3D 是分布式副本集群；双机主备是两个独立 standalone 通过 VIP 和单向 Pipe 自动切换。前者可以横向扩展容量，后者只解决接管与追平，不能把两台机器吞吐相加。

4. 容量测试必须同时记录的指标

任何只有“lag 是多少”的压测结论都不完整。

层级	指标	绿色形态	黄色信号	红色信号	用途
入口	设备、messages/s、points/s、publishErrors	符合目标且失败 0	速率抖动 >5%	设备掉线或发送失败	确认负载真实存在
Kafka	total lag、分区 lag、lag 斜率、rebalance	5 分钟后回到基线带，斜率≈0	高于基线但持续回落	连续 3–5 窗口单调增长	判定真积压而非在途
规则引擎	total/success/timeout/failed、pack 耗时	success=total，timeout=failed=0	p95 接近 pack timeout	timeout/failed 非 0	区分 Kafka 现象与业务处理瓶颈
IoTDB 缓冲	pending、added、written、failed、RPC、backpressure	failed/RPC fail/backpressure=0，pending 不单调上涨	pending 折算 1–5s 流量	pending >5s 且继续上涨	直接看写入余量
IoTDB RPC	flushAvg、flushMax、points/RPC	Avg 低于窗口的 30%，Max 偶发 <2s	Avg 数百 ms 或 Max 频繁过秒	Avg 连续秒级、RPC 失败	判断窗口太小还是 DataNode 过载
JVM / 容器	CPU、heap、old gen、GC pause/time、RSS、OOM kill	CPU <70%，内存有 20% 余量，old gen 可回落	GC 占比升高、RSS >80%	GC 持续接近 100%或 OOM	发现短测看不到的长跑雪崩
磁盘	占用率、iowait、吞吐、await、WAL/TsFile/compaction 增长	占用 <70%，iowait 稳定	占用 70–85%，compaction 债务增长	>85%或 await 持续高	判定 CPU 还是磁盘天花板
查询	latest/history p50/p95/p99、slow、timeout、queue reject	写入指标不因查询明显恶化	p95 升高但写入稳定	查询使 lag/pending 增长	验证真正生产混合负载

建议新增两个派生指标： pendingSeconds = pendingPoints / pointsPerSecond； recoveryHeadroom = consumerRate / producerRate - 1。这两个指标比 pending 和 CPU 的绝对数更容易跨规模比较。

5. Kafka 与规则引擎调优点

这一层决定消息被多快交给 IoTDB，以及物理写入后 offset 多快提交。

参数	优先级	作用	什么现象才调	建议阶梯	回退条件
队列 `partitions`	P1	提高规则引擎并行度	CPU、IoTDB 有余量，但单分区消费速率到顶	50 → 64 → 80 → 100	rebalance 频繁、线程数/连接数激增但吞吐改善 <10%
`consumerPerPartition`	P1	每分区独立消费，避免单消费者聚合大 fetch	多分区已启用，需要明确 1:1 消费	当前 true，保持	消费端资源成为新瓶颈
`TB_QUEUE_KAFKA_MAX_POLL_RECORDS`	P0	平衡 poll/commit 开销和单轮在途量	恢复不够快或稳态在途过大	以 200 为基线；增容时测 250/300/500	poll=100 已证实不可持续；调大后稳态 lag 必然上升
`TB_QUEUE_KAFKA_MAX_PARTITION_FETCH_BYTES` / `TB_QUEUE_KAFKA_FETCH_MAX_BYTES`	P1	限制单分区和总 fetch 响应大小	出现大 buffer 分配、网络抖动或超大响应	4MiB / 8MiB 起点，按单消息体积验证	fetch 次数明显上升且吞吐下降
`TB_QUEUE_KAFKA_MAX_POLL_INTERVAL_MS`	P2	避免慢批次被 Kafka 判定失活	物理写入偶发超长并伴随 rebalance	300000 → 600000	不能解决真慢；只是延长失效判定
`packProcessingTimeout`	P0	规则引擎等待整批完成上限	IoTDB 成功但 pack timeout 导致 offset 不提交	必须 > flush 窗口 + p99 RPC；大规模可 30–60s	调大后仅消除超时日志，lag 斜率无改善
`ACTORS_SYSTEM_THROUGHPUT`	P1	减少热点 Actor 频繁切换	Actor 调度占 CPU，热设备/规则链等待	5 → 20 → 50 → 100	低流量 Actor p99 延迟明显变差
Rule/device/tenant dispatcher pools	P1	增加 Actor 处理并发	CPU 有余量、队列等待高，IoTDB 仍有余量	每次只加 25%–50%	CPU >80%、上下文切换上升、IoTDB pending 反而增加
`ACTORS_RULE_DB_CALLBACK_THREAD_POOL_SIZE`	P1	处理 IoTDB Future 完成回调	IoTDB flush 已完成，但规则引擎完成速率落后	50 → 96 → 128 → 192	线程增加但 completion 速率不变

6. ThingsBoard 内 IoTDB 写入参数

这一层是目前最有价值的调优面，但必须看“每 RPC 点数”与“入库延迟”的取舍。

参数	优先级	调大的效果	调小的效果	建议测试方法
`IOTDB_WRITE_FLUSH_INTERVAL_MS`	P0	更深攒批、RPC 减少、吞吐上限提高；入库延迟增加	更实时、offset 更快完成；RPC 按比例增加	250 → 500 → 1000 → 2000ms；每档记录 RPC/10s、points/RPC、lag 恢复、p95 入库
`IOTDB_WRITE_SHARDS`	P1	增加 flush 并行，也增加 RPC、线程和小批次	批次更深、RPC 更少，但单分片可能成为瓶颈	用 64 作示例基线，测 48/64/80/96；必须根据实际 CPU 而不是容器看到的宿主总核数
`IOTDB_WRITE_BATCH_SIZE`	P2	单设备更多时间戳行才立即 flush	高频单设备更早保护内存	当前 1000 通常不是触发点；只在单设备高频多时间戳场景测 500/1000/2000
`IOTDB_WRITE_MAX_PENDING_PER_SHARD`	P0	允许更多内存积压，延后背压	更早保护内存，但可能误伤正常攒批	用计算器公式；建议为每分片窗口点数的 2–3 倍
`IOTDB_WRITE_MAX_BACKPRESSURE_WAIT_MS`	P1	值越大越偏数据不丢，但规则引擎可被长期占用	更快失败释放线程，代价是依赖上层重试/丢弃策略	数据安全优先保持 0；只在 SessionPool 有限超时后仍会拖死全链路时设置正值
`IOTDB_POOL_SIZE`	P1	更多并发 Session，同时增加 DataNode 连接与并发压力	保护 DataNode，但可能在客户端等待连接	连接池需要覆盖有效 flush 并发；看 session wait 耗时而不是盲目用 2×CPU
`CONNECTION_TIMEOUT / SESSION_WAIT_TIMEOUT`	P0	容忍慢 RPC，但故障恢复更慢	更快失败和释放 pending，但容易误杀短抖动	必须有限；基线 15s/10s，根据真实 p99 而不是随意改为无限

最重要的联动规则： 调大 flush 窗口时，必须重新计算 pending 水位；调大 shards 时，必须同时看 RPC 次数和每 RPC 点数。否则会出现“线程更多，批次更小，总吞吐反而更低”。

7. IoTDB DataNode 调优点

DataNode 参数只有在指标证明服务端是瓶颈时才应调整。

IoTDB 1.3.x

参数 / 资源	优先级	解决什么	什么时候调	调整方向	风险
`DATANODE_MEMORY_SIZE` / 容器 limit	P0	DataNode 堆、堆外和序列基数容量	old gen 长期不回落、GC 占比升高、高序列基数长跑雪崩	当前可以 72G DataNode 预算 / 96GiB 容器为参考；增容仍要留 20%左右原生与页缓存	堆过大会延长 GC；容器上限过紧会 OOM kill
`datanode_memory_proportion`	P1	在存储、查询、schema、共识等之间分配内存	已确认是 schema、查询或写入内存某一段不足	高序列基数可参考 `3:2:4:1:1:1`；写入优先且 schema 余量大时再把配额还给存储	加一段必然减另一段，不是总内存增容
`schema_memory_proportion`	P1	SchemaRegion / SchemaCache / PartitionCache 内部配额	大量新序列、schema 507、schema cache 抖动	同构设备优先考虑 schema template；参数可从官方默认 5:4:1 与当前 6:3:1 对比	过度给 SchemaRegion 会挤压 cache
`data_region_per_data_node`	P1	提高 DataRegion 并行与负载分布	DataNode CPU 有余量，少数 Region 热点，单 Region 写入到顶	4 → 8 → 12/16，每档需新建测试库或核对存量 Region 是否重分布	更多 Region 增加内存、WAL、文件和后台任务
`flush_thread_count`	P2	MemTable 刷盘并行	flush 队列持续增长且磁盘/CPU 仍有余量	默认 0=自动通常保持；只在指标证明自动值不合适时显式设置	过多线程会增加磁盘竞争
`compaction_thread_count`	P1	消化 TsFile 和合并债务	小文件/候选合并持续增长，查询逐渐变慢	SSD/NVMe 可 4 → 8 → 12；每次同时看 iowait 和前台 flush	合并会与前台写和查询抢 CPU/磁盘
`wal_mode`	P0	写入持久性与 fsync 延迟	根据业务持久性要求选择，不是临时调吞吐	当前 `ASYNC` 为吞吐优先；强制 fsync 才用 SYNC	不应为压测数字盲目 DISABLE；集群共识也可依赖 WAL
`disk_space_warning_threshold` / TTL	P0	避免磁盘写满导致数据库故障	所有生产环境	运维预警建议早于 IoTDB 硬阈值；/data 70% 开始规划，85% 阻止扩容测试	`IOTDB_TTL_MS=0` 会无限增长，必须有容量预算或 TTL

Apache IoTDB 1.3.x 官方将 datanode_memory_proportion 定义为存储/查询/schema/共识/流/空闲内存比例，并将 storage_engine_memory_proportion 用于写入与合并的内部分配。调整时必须保留调整前后的堆、GC、flush、compaction 证据。

8. 查询与写入混合压测

只测写入会高估生产容量，尤其是 dashboard、latest、告警过滤和大时间窗聚合并发时。

参数 / 设计	目标	建议	不良信号
`IOTDB_READ_POOL_SIZE`	读连接与写连接物理隔离	以 64 为当前基线；按实际查询并发和 DataNode 能力调整	读池加大后查询 p95 不降、DataNode CPU/内存却上升
`IOTDB_READ_QUEUE_CAPACITY`	有界等待，避免无限排队	保留有界队列和 fast-fail；满队时由上层降级/重试	为减少拒绝而无限放大队列，导致请求在内存中堆积
`IOTDB_QUERY_TIMEOUT_MS`	限制慢查询占用资源	基线 60s；查询 API 本身应有分页、时间范围和 path 数限制	通过不断加大 timeout “修复”慢查询
`IOTDB_READ_SLOW_QUERY_MS`	保留慢查询证据	保持 1000ms 或按 SLA 收紧	为减少日志而关闭慢查询指标
DataNode `enable_query_memory_estimation`	大查询执行前估算内存	保持 true，宁可快速拒绝超宽查询	关闭后大查询导致 DataNode 全局 GC/OOM
latest 存储	减少 dashboard 对历史库的读压力	当 latest QPS 成为瓶颈时，对比 Redis 与 IoTDB Last Cache；用业务契约决定	未区分 latest 与历史查询便盲目增加读池

混合负载最小集

latest

50–200 QPS

按真实 dashboard 和告警轮询节奏

单设备历史

10–50 QPS

1h/24h 窗口，含分页

聚合查询

5–20 QPS

分开 1h/24h/7d，记录 p99

大规模实体过滤

独立场景

重点看 N×K latest 查询放大

9. 每次扩容都按同一套阶梯压测

容量上限不是某个瞬时峰值，而是能长时间运行、能恢复、还能查询的水位。

冻结基线保存 JAR checksum、.env、队列配置、IoTDB 配置、容器 limit、数据量、序列数和磁盘占用。

分开冷启动与热稳态新设备/新 key 首写会创建序列，必须作为单独“冷 schema”场景，不得与稳态吞吐混成一个结论。

5 分钟启动恢复允许全量启动产生 lag，记录峰值、转折点、回到稳态带的时间和恢复斜率。

30 分钟稳态检查 lag 斜率≈0、pending 不单调上涨、failed/RPC fail/backpressure=0，同时记录 p95/p99。

人为制造积压再恢复在可控测试环境暂停消费 30–60s，恢复后测实际消费余量和 ETA；生产不随意做此项。

30–60 分钟读写混合加入 latest、历史、聚合和实体过滤，确认查询不会把写入拖成 lag。

2 小时浸泡发现 GC、memtable、compaction 债务等 5 分钟压测无法暴露的缓慢劣化。

24 小时候选生产测试对拟上线水位测日夜周期、TTL、compaction、磁盘增长和查询波峰。

建议负载阶梯

档位	以当前 8000 设备为基线	目标	通过条件
70%	5600 台 / 约 70 万点/s	确认测试环境和数据模型	全绿，不应需要任何特殊调参
100%	8000 台 / 约 100 万点/s	复现当前生产基线	5 分钟内恢复，30 分钟无增长趋势
115%	9200 台 / 约 115 万点/s	建立生产余量	至少 2 小时稳定，读写混合不恶化
130%	10400 台 / 约 130 万点/s	寻找下一瓶颈	允许黄色指标，但不允许失败或单调积压
150%+	12000+ 台 / 150 万+点/s	找极限，不作生产水位	记录最后绿色档和第一失败档，立即回退

10. 症状 → 参数 → 验证动作

压测时优先从这张表定位，不要同时改五个参数。

症状	最可能根因	第一动作	第二动作	验证通过
5 分钟后 lag 仍快速上涨，pending 低	Kafka/Rule Engine 处理余量不足	看 timeout/failed、pack 耗时、Actor CPU	在 IoTDB 有余量前提下增分区/调 dispatcher、callback	success=total，lag 斜率转负
lag 和 pending 同时上涨，flushAvg 正常	客户端攒批/并发不合理	统计 points/RPC 与 RPC/s	增大 flush 或调整 shards，一次只改一个	RPC 成本下降，恢复加快，入库 SLA 仍达标
flushAvg/Max 持续升高，DataNode CPU 高	Region、写内存或序列基数达顶	看 GC、Region 热点、schema 内存	内存预算/比例、Region 阶梯，或转集群	flush p95 下降且 GC 可回落
flush 慢，CPU 不高，iowait/await 高	磁盘/WAL/compaction 竞争	看 WAL、TsFile、compaction 目录与后台债务	WAL/数据分盘、SSD/NVMe、调 compaction 并发	iowait 下降，前台 flush 恢复
backpressure>0，flushAvg 仍只有几十 ms	pending 水位过小	按公式重算每分片窗口点数	把水位调到 2–3 倍并核对内存上界	backpressure=0，其他指标不变差
backpressure>0，flushAvg 秒级	IoTDB 真过载	立即降载，保留 Kafka 数据	查 DataNode GC/磁盘/Region/合并并规划扩容	不靠加大 pending 隐藏过载
短测通过，50 分钟后 GC 雪崩	序列基数/长期 memtable 与合并债务	按活跃序列数计算 DataNode 堆	增堆、schema template、降生产水位或集群	2h/24h old gen、GC、pending 无单调恶化
一加历史查询就 lag	读写内存或磁盘争用	确认读/写 SessionPool 物理隔离	限查询并发/时间窗，调 DataNode 查询内存，必要时分机	查询 p95 达标且写入 lag 基线不变

11. 这些情况下不要继续加参数

参数只能发挥硬件和架构已有能力，不能无限创造吞吐。

内存天花板

GC 持续恶化

加线程、分区和 pending 只会更快雪崩；应加内存、降序列基数或分机/集群。

磁盘天花板

iowait 持续高

增加 compaction/flush 线程可能更差；应换 SSD/NVMe、分 WAL/数据盘或分机。

架构天花板

长期 >70%

目标负载已接近单机长跑实测上限 70%，应规划 TB/IoTDB 分机或 IoTDB 集群。

可观测性不足

只知道 lag

没有 pending、flush、GC、iowait和查询 p95 前，继续调参属于猜测。

典型反模式

为了看到 lag=0 而在 IoTDB 真正落库前提交 Kafka offset。
用调大 pending 掩盖 DataNode 写入速率不足。
将 Kafka max.poll.records 从 200 一步调回 8192，造成超大在途批次。
同时改 flush、shards、Region、Actor pool 和堆，最后无法知道哪项有效。
只测 5 分钟就宣布生产容量，忽略 50 分钟后的 GC/合并债务。
把首次创建百万序列的冷启动结果当作稳态吞吐，或反过来只测预热数据。
为提升数字关闭 WAL、查询内存估算或背压，使测试与真正生产语义不一致。

12. 每一轮压测的记录模板

保存这张表，后续才能形成自己的容量曲线，而不是重复猜参数。

试验编号	唯一变量	设备/点速率	冷/热	查询负载	lag 峰值/恢复	pending p95	flush Avg/Max	RPC/10s	GC/iowait	结论
T-001	flush 250→500ms	8000 / 1M	热	latest 100QPS	填写	填写	填写	填写	填写	保留/回退
T-002	partitions 50→64	9200 / 1.15M	热	混合	填写	填写	填写	填写	填写	保留/回退
T-003	Region 4→8	10400 / 1.3M	新库	混合	填写	填写	填写	填写	填写	保留/回退

上线门槛

5 分钟启动窗口后，lag 回到已定义的在途基线带，且无持续增长趋势。
IoTDB failed=0、rpcFailures=0、backpressure=0，pendingSeconds 不单调上涨。
规则引擎 timeout/failed 为 0，发送端 publishErrors 为 0。
完成至少 2 小时浸泡和读写混合；候选生产容量建议完成 24 小时。
目标水位不超过长跑实测极限的 70%，或已用 115%目标负载证明余量。

官方参考

Apache IoTDB 1.3.x Common Configuration — 内存、Region、查询、flush、compaction 等参数与生效方式。
Apache IoTDB Monitor Tool — Prometheus 指标暴露和监控接入。
Apache IoTDB Maintenance Statements — SHOW VARIABLES 等运维核查方式。
Apache IoTDB Database Resources — 序列基数、内存与存储容量估算参考。