我一个个来也不行 还是提示上面的报错,有点奇怪,那高有任务还在跑,show jobs 显示不了??
您好,最后咋样了啊?
我重现部署了服务,还在测试中,你们其他一个人的说的
storage挂掉有很多可能,有可能是操作系统的限制,把进程杀掉了;也有可能是OOM了,也有可能是bug导致。一般进程挂掉后,会生成一个core.xxxx的文件,可以通过这个core文件破案。
如果没有生成core文件,执行以下命令后再观察一下,下次挂掉就会有core文件了:
ulimit -c unlimited
如果有core.xxx 文件,执行下边命令查看一下堆栈:
gdb nebula-storaged core.xxx
bt
所以,你按照我们研发同学的操作之后什么结果呢
现在导入数据可以了,storage 没有挂,但是创建索引 会有部分storage 失败
这个问题索引问帮看看,这边生产使用中比较急,先帮看看
索引的问题我们的同事在看
storage 挂了是什么原因,有帮分析出结果吗
rebuild_index_batch_num , 把这个参数调小试试。
这个是在那个storage配置文件中设置吗。我文档中没有看到
是的,在nebula-storage.conf里设置,默认是1024.
好的。谢啦,2.0.1 文档中没有这个参数说明,希望补充一下参数说明
因为2.0 目前相比要花费更多的内存,所以cache就没建议那么大的值。
请问楼主 部分节点建立索引失败的问题解决了吗,我也碰到了,重启后还是会有失败节点。。
你的数据量多少,如果数据量大了
1.改为依次创建索引,同时不要用rebuild tag index 这个来rebuild 全部索引,这个亲测2.0有问题不稳定,还是一个一个rebuild 同时等待一个rebulid成功了,用 show tag index status 查询是否完成,才执行下一个,
2.storage.conf 配置文件 中设置一下这个参数值默是1024 调小一下比如 --rebuild_index_batch_num=512 ,这样可能创建索引时间边长了
我的数据量是10亿节点,7亿边,4个节点集群,每次只能rebuild成功 1-2个节点,请问这是为什么,参数都是默认的。(只rebuild一个索引,不存在多个索引同时rebuild的情况)
这边要提升性能和避免OOM,那这边128G内存,2.0版本可以设置多少 默认4M 是不是太小了,和1.0 的默认1g 相差太多,还有确定一下这个参数1.0 和2.0 是同一个含义吗,还是不同的配置只是名称一样