最近 Windows 服务器上的内存使用率高达 95%，调查发现物联网时序数据库 InfluxDB 吃掉了90%的内存。当服务器内存使用率高达95%时，离服务器崩溃也就不远了。在服务器重启后，有时是半个月，有时是一个星期，内存使用率再次飙升，直至崩溃，这是为什么呢？
一、InfluxDB占用内存分析
既然发现是时序数据库 InfluxDB 吃内存，先看看它是怎么吃内存的吧。
在InfluxDB 启动时，使用的内存大约为 1G，服务器的总内存为 15.5G，加上其他内存占用，整个服务器的内存使用率大约为 30%。但是随着时间的推移，InfluxDB 内存占用率越来越高，第二天占用内存 3.7G，第三天占用内存 4.2G，一天又一天过去，内存迅速飙升，直到服务器承受不住崩溃重启。
网上的很多资料，都是针对Linux系统排查的，使用Windows做服务器的几乎没有。系统虽然不一样，但思路是一样的。
二、InfluxDB内存优化
经过一番调查，发现有两个原因导致 InfluxDB 时序数据库吃内存。这也促成了两次优化。
1、第一次优化，分片索引优化
InfluxDB在启动时，需要将索引加入到内存中，默认的是内存分片索引，这个需要更改为 基于时间序列（TSI）磁盘的索引。
第一步，更改配置文件 influxdb.conf 中的配置。
#influx索引
#默认为inmem,创建内存型索引,在delete retention会消耗过高内存
#[优化点]:降低删除保留策略时的内存消耗
index-version = "tsi1"
还有其他一些消耗内存但是不是必须的配置，比如上报功能，如果不需要也关了吧。
第二步，重建 TSI 索引
1、停止 InfluxDB 服务
2、移除所有的 _series 文件
来到 /data/<dbName>/ 目录下，将 _series 文件都删除；
3、移除所有的索引文件
来到 /data/<dbName/<rpName>/目录下，逐一打开shardID文件，将文件下的 index 文件夹删除；
4、重构 TSI 索引
使用influx_inspect命令行客户端 （CLI）重建 TSI 索引
填充 data、wal路径，执行 influx_inspect 命令
influx_inspect buildtsi -datadir <data_dir> -waldir <wal_dir>
5、重启 InfluxDB 服务
官网参考：https://docs.influxdata.com/influxdb/v1.8/administration/rebuild-tsi-index/#Copyright
这两步优化必须一起做，如果只更改了配置，而没有进行TSI索引重建，那么是达不到优化效果的。
InfluxDB做了这次优化后，再次启动，内存占用率从1G降到0.6G。
虽然启动内存占用率减少了，但是随着时间一天天过去，内存使用量依旧在飙升，这又触发了第二次优化。
2、第二次优化，连接资源的释放
InfluxDB每个小时都会收到大量的插入数据请求，查询次数并不多，这些请求资源能及时释放吗？
Go1.17默认是使用 MADV_DONTNEED ，那为什么程序的RES并没有减少呢？是因为GC在回收对象时，并不会将内存直接返回给操作系统，而是先放回预先分配的大块内存中，以便复用。所以Go程序的内存即使被GC回收了，也不会立刻归还给操作的。
https://colobu.com/2019/08/28/go-memory-leak-i-dont-think-so/
由此推断，是go没有及时释放内存导致。
InfluxDB服务器端启动配置调整：
# Linux下调整
# 使用env GODEBUG=madvdontneed=1参数，强制每次释放内存时，将内存交给系统
set HOME=D:\influxdb-1.8.3-1
influxd.exe -config influxdb.conf env GODEBUG=madvdontneed=1
#Windows系统下更改
set HOME=D:\influxdb-1.8.3-1&&GODEBUG=madvdontneed=1
influxd.exe -config influxdb.conf
在测试环境，使用模拟数据进行测试。
InfluxDB内存占用率出现了起伏，刚开始启动0.6G，然后上升到1G，最多1.5G，接着缓慢下降0.8G，又下降到0.6G，最后又开始新的一轮起伏。很明显回收内存起作用了。
三、最后总结
这次内存优化，主要是根据现象进行分析，有盲猜的成分在里面。其实可以借鉴网友的经验，比如这个网址：https://zhuanlan.zhihu.com/p/358012882
使用一些命令，根据具体的指标，来对问题进行定位：
1、使用influx客户端，查看influx服务的运行状态
# 查看内存空闲、使用、释放的额度
show stats
HeapIdle：堆空闲；
HeapInUse：已使用堆空间；
HeapReleased：已释放空间；
按照go的内存分配空间布局规则，可以根据如下计算方式
当前堆内存=HeapIdle-HeapReleased+HeapInUse。
2、是否存在内存泄露
#当前influxd进程id为700
#1.pmap命令查看进程内存块分配
pmap -x 700|less
#2.查看更详细的每一块内存分配
#命令:cat /proc/pid/smaps
#如下发现进程堆内存地址空间为:c000000000-cff4000000
cat /proc/700/smaps | less
#3.使用gdb打印堆栈
gdb -p 32309
#输入程序地址空间0xc000000000 0xcff4000000
dump binary memory ./meminfo.log 0xc000000000 0xcff4000000
#查看内存调用栈backtrace
bt
#4.查看内存内容meminfo.log
hexdump -C ./meminfo.log | less #查看内存块数据
3、如果磁盘需要优化，可以关注以下两个指标
#说明: wal预写日志log,用于事务一致性
#默认为0，每次写入都落盘。
#修改为1s, 根据业务场景，不保证强一致性,可采用异步刷盘
#[优化点]:用于减轻磁盘io压力
wal-fsync-delay = "1s"
#说明: 压缩TSM数据,一次落盘的吞吐量
#默认48m
#修改为64m
#[优化点]:增大写入量，减轻io压力
compact-throughput = "64m"
以上便是本次整理，希望对你有所启发。
