问题原因
之前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重构来解决,对于分布式的性能下降,百分之十几左右的性能下降符合预期。后续可以进一步分析分布式下性能下降的原因。