system_memory_high_watermark_ratio,memory_tracker_limit_ratio参数使用疑问


版本3.4.0。混合docker部署的情况下,(studio,三个graph,metad,storage。都在一台服务器)
举例:
sys:26.775GiB/40.000GiB 66.94% usr:25.414GiB/31.961GiB 79.52%
具体有较多疑问,想咨询下这两个参数的使用:
1、usr:31.961GiB 这个数值的限制是怎么来的呢?它是哪些服务的内存使用最大值总和呢?(studio,三个graph,metad,storage)
2、system_memory_high_watermark_ratio是操作系统层次的内存监控,查询到有些情况下是防不住OOM Kill的是吗?
3、如果希望三个graph,三个storage内存分别占系统的0.5,0.3;是每个graph的memory_tracker_limit_ratio为0.5的1/3,还是都是0.5呢(storage同理)。
4、studio,metad也能使用这两个参数吗,目前只在graph和metad文档看到。
5、studio的内存使用会随着查询数据量的增大会变得很大吗,还是只会是graph的内存增大。假设限制了三个graph,metad,storage内存使用,如果studio内存不停增长,导致虚机OOM Kill这段时间会严重影响服务器其他业务,也连接不上虚机。

1、usr:31.961GiB 这个限制是通过 (total-FLAGS_memory_tracker_untracked_reserved_memory_mb) * memory_tracker_limit_ratio计算得到的,详见

https://github.com/vesoft-inc/nebula/blob/cc84693998987bcf9e8fddad2ace385e0cb860a7/src/common/memory/MemoryUtils.cpp#L151
它是每个服务进程单独配置的,目前只有graphd,stroraged支持该配置;

  1. 是的system_memory_high_watermark_ratio是系统层次的,是memory tracker之前的一个内存监控配置项,后续会deprecate掉,在一些情况下,防不住OOM

  2. 0.5的1/3

  3. 不能,目前占用内存大头主要是graph/storage, meta和studio没有这些配置项;

  4. studio理论上不会占用大的内存,我们建议这些服务尽量不要混合部署,每个服务单独部署是更合理的部署形式;

2 个赞

5.studio理论上不会占用大的内存,我们建议这些服务尽量不要混合部署,每个服务单独部署是更合理的部署形式;

感谢您的解答,关于第五条建议,目前在Docker部署的混合方式中,在docker stats 查看容器运行时内存时观察到,studio在查询大量数据时,内存的使用甚至比graphd占用更高,且会持续较长时间,当下一次查询开始studio内存开始下降。
观察结果:
当混合部署是graphd如果查询没有结果,studio的内存不会变化,当graphd查询数据较大,studio内存占用较大且时间较长,也是我们当时服务崩溃的原因。

1 个赞

OK, 感谢反馈,如果查询返回的结果集很大时,的确可能出现studio存储结果集也会占用大量内存。

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。