问题原因

之前IoTDB用户在11月初的时候发现分布式在开启时间分区后，性能出现严重下降。用户测试的时候使用了flink进行写入。

关闭时间分区时：

开启时间分区时：

用户使用三节点一副本IoTDB集群，IoTDB 0.12.2版本，可以看到开启时间分区前后，性能下降比较严重。

问题排查

针对这个现象，我们希望能够给新版本提供一些参考经验，因此我们直接在master branch上进行了一些测试。

我们首先对单机模式的IoTDB开启时间分区进行测试，在排除单机IoTDB的影响下，后对分布式模式进行测试。

测试环境

• 8 Core

• 20G memory

• 10000 Mb/s

• Ubuntu 20.04.2

benchmark参数

• CLIENT_NUMBER=5

• GROUP_NUMBER=8

• DEVICE_NUMBER=400

• SENSOR_NUMBER=100

• BATCH_SIZE=100

• POINT_STEP=100000

• LOOP=10000

• OPERATION_PROPORTION=1:0:0:0:0:0:0:0:0:0:0

• DB_SWITCH=IoTDB-012-SESSION_BY_TABLET

在该配置下进行测试，发现写入会直接block住，根据jstack的线程dump结果分析：

某个client线程拿到sg写锁后，需要等待wal的buffer，但wal buffer一直没有被释放，因此导致写入卡住。

后续分析原因得知，当时间分区的数目增加，前面时间分区没有新数据写入，对应的memtable未flush到tsfile中，导致tsfile无法关闭，wal的buffer也无法释放。

此时需要调整IoTDB-engine.properties中的几个参数才可以正常写入，

• concurrentWritingTimePartition = 4

• enableTimedFlushSeqMemtable = true

• seqMemtableFlushInterval = 60*1000

• closeTsFileIntervalAfterFlushing = 60*1000

在该配置下，未开启时间分区时：

开启时间分区后：

调整IoTDB配置后，单机开启时间分区前后性能基本一致。

下面进行分布式测试：

集群配置

3 nodes, 1 replica, multi-factor=1

单机配置与之前的测试相同

benchmark参数

• CLIENT_NUMBER=10

• GROUP_NUMBER=16

• DEVICE_NUMBER=4000

• SENSOR_NUMBER=100

• BATCH_SIZE=100

• LOOP=10000

• POINT_STEP=100000

• OPERATION_PROPORTION=1:0:0:0:0:0:0:0:0:0:0

• DB_SWITCH=IoTDB-012-SESSION_BY_TABLET

未开启时间分区时：

开启时间分区后：

每个存储组共16个时间分区，开启时间分区后性能下降17%。

问题结论

目前单机下的WAL存在问题，需要通过后续的WAL重构来解决，对于分布式的性能下降，百分之十几左右的性能下降符合预期。后续可以进一步分析分布式下性能下降的原因。