system_memory_high_watermark_ratio，memory_tracker_limit_ratio参数使用疑问

问答 问题
1

image
image1883×442 43.8 KB

image
image1840×638 68.6 KB

版本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这段时间会严重影响服务器其他业务，也连接不上虚机。
2

1、usr:31.961GiB 这个限制是通过 (total-FLAGS_memory_tracker_untracked_reserved_memory_mb) * memory_tracker_limit_ratio计算得到的，详见
https://docs.nebula-graph.com.cn/3.5.0/5.configurations-and-logs/1.configurations/3.graph-config/#memory_tracker

https://docs.nebula-graph.com.cn/3.5.0/5.configurations-and-logs/1.configurations/4.storage-config/#memory_tracker

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 个赞
3

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

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

1 个赞
4

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

5

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