今天执行了SUBMIT JOB STATS命令，然后内存使用超限，storaged exited.
重启后，服务接收写入命令，很快又超限了storaged exited。现在不停数据写入服务，storaged服务重启后很快就退出，没法用图库了。
试了以下方法均无效：
1、memory_tracker_limit_ratio =0.95
2、–containerized=true
–cgroup_v2_controllers=/sys/fs/cgroup/graphd/cgroup.controllers
–cgroup_v2_memory_stat_path=/sys/fs/cgroup/graphd/memory.stat
–cgroup_v2_memory_max_path=/sys/fs/cgroup/graphd/memory.max
–cgroup_v2_memory_current_path=/sys/fs/cgroup/graphd/memory.current
上面memory.max设置的15G对应的字节大小值，总内存16G.
内存使用超限：这通常是因为NebulaGraph在执行某些操作时（如SUBMIT JOB STATS）需要大量内存，但可用内存不足导致storaged服务崩溃。
解决步骤：
调整memory_tracker_limit_ratio：
你已经尝试将memory_tracker_limit_ratio设置为0.95，但这没有解决问题。可能需要进一步降低这个比例以确保内存不会超限。尝试设置一个更低的值，如0.8或者0.7：
memory_tracker_limit_ratio = 0.7
这个值表示内存使用达到总内存的70%时会触发限制。
检查和调整RocksDB配置：
NebulaGraph使用RocksDB作为存储引擎，RocksDB的某些配置可能会影响内存使用。特别是：
block_cache：减少缓存大小。可以在nebula-storaged.conf中配置：
--rocksdb_block_cache=1G
write_buffer_size：降低写缓冲区大小：
--rocksdb_write_buffer_size=64MB
max_write_buffer_number：减少最大写缓冲区数量：
--rocksdb_max_write_buffer_number=2
使用cgroups进行资源限制：
你已经尝试了容器化的方法，但配置可能不完全正确或者没有覆盖到所有的storaged进程。确保你为每个storaged进程都应用了相同的限制：
创建一个新的cgroup目录用于storaged：
sudo mkdir -p /sys/fs/cgroup/storaged
设置内存限制（如15G）：
echo 16106127360 > /sys/fs/cgroup/storaged/memory.max
然后在nebula-storaged.conf中添加或修改以下配置：
–containerized=true
–cgroup_v2_controllers=/sys/fs/cgroup/storaged/cgroup.controllers
–cgroup_v2_memory_stat_path=/sys/fs/cgroup/storaged/memory.stat
–cgroup_v2_memory_max_path=/sys/fs/cgroup/storaged/memory.max
–cgroup_v2_memory_current_path=/sys/fs/cgroup/storaged/memory.current
确保服务启动时使用这些配置。
监控和调整工作负载：
检查是否有任何特定的查询或操作导致内存使用激增。可能需要调整查询策略或数据导入方法。例如：
分批次执行STATS任务，而不是一次性执行所有。
使用LIMIT来控制查询返回的数据量。
硬件升级或分片：
如果你发现即使经过以上调整内存仍然无法满足需求，可能需要考虑增加服务器内存或通过增加更多的storaged节点来分散负载。
查看日志：
查看storaged服务的日志，了解具体的崩溃原因。可能有额外的错误信息可以帮助诊断问题。
其他建议
确保系统其他进程没有占用大量内存。
检查是否有内存泄漏问题，可能需要联系NebulaGraph社区或技术支持。