大佬，我认为问题不在于schema定义之类的
因为schema和图里的tag和边结构，以及数据写入都在另一个环境的nebula验证过了的
目前的问题在于：
在新建的集群上搭建了一个nebula库
用exchange写入点可以正常写入，写入边一直报E_RPC_FAILURE（-3），然后上graphd的日志就像我发的日志截图一样，大量报超时（此时我认为是导数速度过快storage处理不过来，storaege日志也确实发现了不少minor compact的日志）
然后我在停止exchange导入任务很久后，用studio手工插入单条边数据依然会报E_RPC_FAILURE，所以我认为我之前假设的导入数据速度过快导致storage压力过大导致超时的假设也不成立，因为目前storage目前看没有在干活
所以不清楚该如何继续排查了
补充一下：
当前写入点还是可以正常写入不超时
写边会超时
很困惑
你那边方便的话，可以先测试下看不借助客户端（nebula-studio）和连接器（nebula-exchange），用 nebula-console 看看是不是可以插入边看看么？
然后配置这块：
你看下这个。修改下之后重启下服务，看看不能正常。
有没有改过配置，比如打开实验功能启用TOSS？
你好，没有开启过TOSS
这两个参数我查阅到了论坛里的另一个帖子，里面有人建议这个数字为核数的一半
目前我的storage节点是16C，所以这两个参数的配置是8
请问需要改大么
而且目前我没有手动compact过，看日志storage是有default minor compact
我们可能是被同一个人教育的，他和我说 cpu 的一半。保持统一。
方便的话，试试这个？
看下是不是客户端哪里有问题。
nebula-console这个暂时没有条件诶，环境不太自由，这里说的客户端是指怀疑exchange或者studio有问题吗？
目前是把集群铲掉后，扩大了storage节点的磁盘容量（500G——>1.4T）
之后不会再报E_RPC_FAILURE的错误了，感觉节点的容错能力好像变强了
但是写入边还是有问题：
我有一个不断增量写入点边的作业，通过jar包nebula-client连接nebula，持续不断的少量写入是正常的
但是此时如果开启spark任务开始导入全量数据，会发生两个问题
1、内存被打满，且从dashboard看实际使用内存不高，大部分是缓存
不过这个不至命，在exchange写入点时可以继续写入
2、开始写边后，就开始报raft buffer is full的报错，如我最开始的贴图
我在论坛上翻了不少帖子，还有官方文档
按照最佳实践调整了max_sub_compaction等两个参数，还有rate_limit（因为怀疑是default compact占用了磁盘IO导致 buffer消耗慢）
嗯，排除下。 如果环境不方便的话，你方便把 exchange 的配置贴一贴么？
buff/cache不用管，是可以回收利用的。
那个rate_limit配置去掉啊，那个虽然限制了compaction的写入，但更限制了你的数据写入。
怀疑磁盘I/O，你贴下磁盘的监控，还有CPU和网络
嗯，rate_limit这个后面仔细阅读了参数含义以及去掉了
贴一个比较完整的存量导数过程：
storage配置16C64G，7个storage节点
图schema：35 partition，3 replica
从hive的十几张表里分别读取十几种点边数据，9亿+点，9亿+边
表中的数据量估算在200G左右，每个storage的磁盘空间1.4T，采用的是挂载的方式
关闭了自动compaction，禁用page cache，block cache调整为32G
开始导数后磁盘消耗比预计的差距明显，峰值约1.2T
导数过程截至到下午两点左右，服务器无响应的，可能是内存打满了（node的资源也是64G，这个确实不太合理）
但是他正常运行了约12小时，最终数据点全部写入，边写入了大约70%
磁盘监控：
CPU：
网络：
内存：
1、磁盘占用比预计大了非常多，看了一些帖子猜测是raft buffer overflow这类会导致重试写入，导致写入被放大，又停了自动compact导致又重复数据在磁盘里
2、在10点以后有一个比较明显的磁盘下降，当时磁盘还在写入也没有手动compact，这个有点奇怪不知道原因，有大佬说是临时文件的自动回收
