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