版本1.1.0，分布式部署
场景是24小时不间断地实时写入+查询
现在发现内存占用率，在短时间内看是有增有减，长时间来看是一个持续递增的过程
–rocksdb_block_cache 按官方建议设置为总内存的3分之1(配置了截断策略，1w个点)
想问下还有哪些原因会导致内存占用持续的递增，具体什么样的操作是需要占内存的？
主要是担心有一天内存打满了引起进程crash
补充一下~
1.配置了前缀过滤
2.最核心的就是想知道，它还会不会一直涨，怎么能避免让他一直涨
1 个赞
index和filter会随着写入不断变大，rocksdb的index和filter在默认配置下好像没有计入在block_cache中，如果数据量很大，把storage参数enable_partitioned_index_filter打开就行。目前没有已知的内存泄漏。
麻烦问下 enable_partitioned_index_filter 这个参数不重启能生效嘛？
这个是在哪里改？~
update rocksdb_db_options 嘛？
另外 改了这个会对性能有非常 巨大 的影响嘛？
在storage的conf里加上enable_partitioned_index_filter=true，对读会有影响，巨大不好说，看业务场景，一般场景下如果经常读的数据和不经常读的数据比例在82开的话，经验上说影响很小。实际结果还是得测。
2 个赞
明白了~ 非常感谢！
你可以按这个估算下需要的静态内存量。
https://docs.nebula-graph.com.cn/manual-CN/3.build-develop-and-administration/3.configurations/0.system-requirement/
有请求时候会涨，没请求应该会降下去，你可以试试长期压测一下。
ok~ 我观察下 多谢
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相对已经比较稳定了。
1 个赞
监控的图如果方便，可以贴下我看看
方便加您一下微信吗？我把监控图给您看下 ~ 我在微信群里 kouichi
配置也一起发一下好了
请教了一番 基本上就是我勾了解决方案里那个参数~~
鉴于怕重启影响raft… 打算等内存实在扛不住的时候再重启了… 到时候如果有效果我回来记录~
3 个赞
@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日志关了，所以看不到)