index和filter会随着写入不断变大，rocksdb的index和filter在默认配置下好像没有计入在block_cache中，如果数据量很大，把storage参数enable_partitioned_index_filter打开就行。目前没有已知的内存泄漏。
@critical27
不好意思 还得麻烦下 那我这个服务是24h不间断持续写入的… 是意味着 内存早晚会炸吗？什么情况下他能降下来啊？…
改参数还得重启…重启又不太放心raft…之前的版本经常因为重启raft就错乱了…
不重启有救嘛？
另外 将来能不能有一个参数 能整体限制住内存增长… 不断变大不靠谱哇~~
持续写入不应该内存一直上涨的。memfile 大小和个数都是限制的。
还有一个细节~ 不知影响嘛？
我关闭了auto_compact ，然后定时进行大compact
一周角度看，不应该持续上涨的。
目前观察到的是一个四天的角度…是持续涨 很慌
内存如果不是因为query导致oom，据我所知不会爆，有的业务已经很久没有重启过了。内存没有降可能是因为index和filter默认参数下都会进内存，不断写入就会变大。我建议是重启改下参数，1.1.0相对已经比较稳定了。
监控的图如果方便，可以贴下我看看
方便加您一下微信吗？我把监控图给您看下 ~ 我在微信群里 kouichi
配置也一起发一下好了
请教了一番 基本上就是我勾了解决方案里那个参数~~
鉴于怕重启影响raft… 打算等内存实在扛不住的时候再重启了… 到时候如果有效果我回来记录~
@critical27 @min.wu
我回来了…留个记录…
上周重启的… 到现在大概五六天吧… 内存使用率到80%了…
配置文件中加入了enable_partitioned_index_filter=true这个参数
然后是直接重启的… 没有加那个强制读取本地配置文件的参数… 所以不确定新加的参数是否生效
另外，raft这回确实没挂
但是更神奇的事情发生了… 就是数据全"没"了… 不是底层文件没了，是go查询的时候查不到东西
重启过程如下
1.写入和go查询都未停止
2. 一台一台进行storaged的restart(补充一下 这个重启脚本好像需要修正一下 现在服务还没停掉呢 就开始启动了)
3.一台一套重启期间的时候，观测storaged的error日志可以发现那种忧郁raft切换导致的报错，但都是短时间报错，过一会儿就没了
4.重启期间的时候，进行过几次balance leader操作，也是一些短时间的raft切换的异常
5.重启完成
重启完成后，发现go查询请求都查不到数了，翻看graphd以及storaged的error日志，均未见任何异常。(info日志关了，所以看不到)
查不到应该只是因为leader切换导致查询失败
我记得 show config 是可以看到当前的配置是什么的吧？
有些配置show不出来~ 比如那个前缀索引的相关配置
但是没有报错信息，而且不是短时间查不到数据，是永远也查不到数据了…
开点日志发给我看看，我现在判断不出来发生了啥。底层rocksdb文件都在对吧，确认下那个space下数据都还在？至少你说的重启流程听着没问题。
去Rocksdb目录找找，有个全名就叫LOG的文件里面有这个参数（和其他rocksdb参数）的值。
目前来看应该是生效了，内存使用整体保持在80%左右，因为我们的业务有实时插入和定期离线插入，现在发现的规律大概就是随着实时插入内存会缓慢增长，然后每当出现大批量离线插入的时候，内存就会降下来。
另外主要就是上次丢数的问题了
我后来还是重新灌的数据
我生产环境肯定不敢把日志级别开的太大，但是出了问题第一时间光去修复了，没有来得及放开更多的日志，所以查不到日志了。
另外，确定rocksdb的文件都在，而且我就一个space，所以很好确认。
在什么极端的情况下会出现查不到的情况呢(且graph和storage层均没有报错)？
又过了2周，现在的内存呢？
哈哈哈 如此跟踪的嘛~
内存稳定了，安逸了~