你好，这个是机器资源配置的问题么
graph:
这个报错是缓冲区满了，应该是资源配置的问题啦
今天测试结果，数据也导入完成了。图数据库的连接问题也自动恢复了。有3个问题：
1.导入的数据花费的时间很久，9点-13点，用了4个小时（4核15G内存）。这个在高配置（16核32G内存）的那套环境中，同样的数据量用时也只有20多分钟。
2.有出现丢失数据的情况，如上图。这个在高配置的那套环境中，未出现这个问题。
3.是不是像这样的数据量我们也只能提高资源配置了。在图数据库的相关配置，或者 导入的 .yaml文件 我们没办法做优化了呢？
以上是这几天测试出现的问题，感谢各位老师能给予答复
这个目前我自己分析不出来原因，等周二上班我把问题反馈给同事在看看。不过从importer的实现原理看，他只是把配置和数据最终解析成 gql 语句执行来实现数据的导入，所以这样看配置的高低只会影响数据的导入速度，不会影响丢失。如果想速度快一点，concurrency可以再调大一些？你要不再对比一下文档？使用 NebulaGraph Importer - NebulaGraph Database 手册
这个可能和现在的状况无关了，不过meta和storage日志的时间差的比较多，meta的日志里集群状态是好的，storage的日志里已经连不上meta了，报timeout，所以会显示storage offline。
这个导入速度有点慢，schema中有很多索引吗？
另外，那个丢失数据并不是真正的丢失，只是importer提示有数据导入出错，importer本身也有重现机制，如果你看到导入后实际数据是对的，也没问题。或者就把err目录下的csv重新导入就可以。
schema没创建索引。这个在另外一个集群16核32G内存 执行很快的，20多分钟。数据导入出错应该是超时导致的吧。还有服务器 buffer is full
谢谢。服务器配置低的话，这个concurrency 不能调大吧
应该是可以调的，这里nebula-importer是golang实现的，用了协程来处理并发，比线程的开销小很多，理论上你的那个所谓的低配的配置，这个concurency还可以调的大一些。