1.新的问题
influxdb目前支持内存型索引inmem及文件型索引tsi1。之前追踪篇将influxd索引修改为tsi1之后,经过一段时间的运行,从监控观察到,由于调用方采用异步队列+批处理的方案将数据写入influxdb,会在某些时刻调用方内部出现数据堆积,指标如图:
- 横坐标: 时间轴,从12-29 00:00 到 12-30 00:00
- 纵坐标: 队列中数据堆积长度,坐标最大值250k,即最大25w个数据堆积
从上图可以看到,当天监控出现数次堆积,上午7:00-10:00尤为严重。在堆积时,登录influxdb服务器,查看机器状态如下:
top - 09:40:58 up 120 days, 19:18, 1 user, load average: 32.29, 32.32, 29.82
Tasks: 364 total, 1 running, 363 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.4 us, 0.1 sy, 0.0 ni, 57.7 id, 41.8 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 65433892 total, 376024 free, 30179144 used, 34878724 buff/cache
KiB Swap: 32833532 total, 32689404 free, 26624 used. 34607748 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9571 root 20 0 0.269t 0.053t 0.025t D 14.6 86.2 1081:18 influxd
在出现堆积时,wa很高,说明问题再次出现在磁盘io上,而且influxd的SHR空间占用了25g,又是为什么?
面对新出现的问题,当前的主要手段仍然是从influxdb配置文件入手,但是该如何优化?
2.tsi原理
工欲善其事,必先利其器。
查阅了相关资料之后,整理了influxdb使用tsi索引时原理图:
说明:
- 写入influxdb时,会同时写wal文件及cache内存, wal用于宕机恢复cache
- cache在达到配置中的阈值时,会进行snapshot快照,进行落盘
- influxdb的series及index索引会在内存中全量保存,用于快速检索
- wal文件大小在达到配置中阈值时,会进行压缩转换到index索引
- influxdb会对磁盘数据文件{ {index+data}}按照分片shard维度进行四次压缩(level1,2,3及full),以节约磁盘空间
3.堆积的原因
在队列堆积的时间点,经过多次对比influxdb的日志:
#调用方队列堆积时,influxdb的关键日志如下:
#influx开始执行第四次全量压缩策略,tsm1_strategy=full
ts=2021-01-05T10:30:02.049644Z lvl=info msg="TSM compaction (start)" log_id=0RVRbtjl000 engine=tsm1 tsm1_strategy=full tsm1_optimize=false trace_id=0RWXOKGG000 op_name=tsm1_compact_group op_event=start
...
#省略
...
#第四次全量压缩结束
ts=2021-01-05T10:44:13.931365Z lvl=info msg="T