THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
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左右的性能下降符合预期。