怀疑磁盘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，这个有点奇怪不知道原因，有大佬说是临时文件的自动回收
还有一个感知比较明显的就是插点和插边的区别
插边时raft buffer is full的报错明显增多
这里我最初怀疑是边存储的特殊性导致的，因为之前好像有读到nebula的边存储是有分多个部分的
后面也在想是否是开始的写点操作占满了buffer导致后面的写边时异常比较明显
磁盘占用大是因为raft的wal文件，存量导入的时候可以调整下storaged.conf里的wal_ttl，这个默认4小时，可以改成10分钟，导入完了再改回去。
这个配置可以用curl动态调整，方法可以翻下手册
导入前确保leader是balance的
这个我每次有balance的，偶尔会发新balance后分片有轻微的不均衡，重新balance也没有变化，我一般也就忽略了应该可以吧？
此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。