当前还是无法防止OOM，主要是usr的比例一直都是小于sys的比例，如图：
当前测试场景就是，K8s给graphd一个比较小的资源，然后搞个客户端，频繁执行查询操作
oom的时候，graphd进程实际占了多少内存？容器中还有其他占内存的进程吗？
为了快速验证是否OOM，K8s给graphd的资源limit为2G，因为触发了OOM，graphd进程占用肯定超过了2G，容器内部就1个graphd进程
你好，能否发下你发的query是什么类型的query？
这个我是参考这个链接里的弄的： 基于图数据库的推荐系统 - siwei.io
查询就是把这里的查询全部循环执行一遍，qps大概在4左右
用电影推荐的数据集，查询都是从这个链接里面抄的，另外还有1个写入操作，具体逻辑为循环执行：
1）创建图空间test_x
2）创建点和边
3）插入点（2W*4），边（20W*4）
4）增加点的属性 (给4个tag都alter加上2个属性)
5）更新点的属性 （给上面的8W个点更新属性）
6）删除这个图空间
另外昨天给storaged和graphd设置了memory track ，效果甚微，该OOM的还是OOM：
在不进入容器的情况下，容器里只有1个进程：
graphd的日志：
storaged的日志：
我感觉这个是不是1分钟检测一次？这1分钟之间，可能触发了内存OOM，而且我发现我客户端都大量报错了，graphd和storaged还是OOM了，感觉这个水位线和memory_track都没什么效果…：
看这个过程，发给服务端的query都是DML是吗，目前的memory tracker的确没有对写入过程的内存跟踪
不全是的，查询也挺频繁的，我起了个cronjob，每5s执行了12个查询，然后写入就是直接for循环里面不停弄，具体的GQL，可以看下这个文件里面的，写入的语句是代码里面随机生成的，查询语句是写死的
sql.7z (7.7 MB)
可以试试把写入DML停了，全部用DQL，DQL的查询并发可以大一些，能不能复现问题；
我觉得这个的意义不大，目前我发现，只有DML，graphd的内存和CPU使用极低，反而是storaged的资源占用很高，而且storaged内存疑似内存泄漏，所以我想通过这个方式限制storaged的内存在某一个范围内，只有DQL，graphd的内存和CPU都特别高，但不像sotraged那样内存无限缓慢上升，把DQL停掉，graphd内存就会下降
问题就是我当前其实不太关注graphd是否能够限制住内存，因为我发现graphd内存和查询正相关，这个内存范围我大概是可以测出来的，我更想通过一个参数限制住DML大的情况下，storaged的内存增长，但目前的情况是，没找到合适的，后面可能只能通过定时重启解决了，之后可能就要考虑平替其他数据库了
目前memory tracker的确不track写入路径的内存，storaged的内存增长，可能主要来自rockdb内存使用，比如compaction和blockCache等, 如果是这些模块的内存，可能需要看看rocksdb相关的配置参数，比如调整blockCache大小，调整compation的并发等；
rocksdb调参，人麻了，当前调成这样了：
config:
enable_partitioned_index_filter: "true"
enable_rocksdb_statistics: "true"
memory_tracker_detail_log: "true"
containerized: "true"
memory_tracker_limit_ratio: "0.6"
rocksdb_block_based_table_options: '{"block_size":"32768","cache_index_and_filter_blocks":"true"}'
rocksdb_block_cache: "4"
rocksdb_db_options: '{"max_subcompactions":"4","max_background_jobs":"4","max_open_files":"20000"}'
内存虽然不像之前一样呈斜坡式增长，但仍然呈阶梯式增长，当前就想找个能够控制storaged服务的内存的参数，我太难了 
@codesigner @xjc 大佬们，你看我这个内存，是不是 有点问题，今天又部署了一个环境，看了下日志，感觉好奇怪，storaged有2个节点，内存小到我不敢相信，memory track读到的居然还是负值：
graphd，metad，storaged都是3副本，奇怪的是，都有2个副本的内存占用极低，之前K8s部署的，刚部署完应当都在500多M，感觉是不是少了些什么东西
sys那个为负数不知道什么原因，这个完全是从cgroup里读的，你登录到pod看下/sys/fs/cgroup/memory.current是多少？
副本间内存不一样要不先使用一阵子观察下，连graphd都不一样，应该和nebula关系不太大。
有可能cgroup是v1，你cat /sys/fs/cgroup/memory/memory.usage_in_bytes
