Star

storaged的内存占用如何控制上限?

版本1.1.0,分布式部署
场景是24小时不间断地实时写入+查询

现在发现内存占用率,在短时间内看是有增有减,长时间来看是一个持续递增的过程

–rocksdb_block_cache 按官方建议设置为总内存的3分之1(配置了截断策略,1w个点)

想问下还有哪些原因会导致内存占用持续的递增,具体什么样的操作是需要占内存的?

主要是担心有一天内存打满了引起进程crash

@dangleptr @critical27

bloomfiter一般都是最大的部分。

补充一下~
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日志关了,所以看不到)

浙ICP备20010487号