nebula 版本：v3.4.0
部署方式：单机
安装方式：Docker
是否上生产环境：N
目前数据库里面应该只有2w多的点和4w多的边，但是重建索引一直处于running状态，导致后面的job都处于阻塞状态。
两个问题：1.是不是多个索引的rebuild不能同时提交
2.同一时间nebula是不是只能处理一个job，相当于所有的job都是串行的
另外，当我stop掉重建索引的job后，后面再重新rebuild，会立刻失败。
把 storage 和 meta 的日志贴一下呢？
稍后我贴一下，不过这个应该是必现的，就是同时提交多个索引的rebuild任务
又发现了另一个问题，当我看storage的日志的时候，发现storaged-stderr.log竟然有39G，tail -f发现会滚动打印
I20230323 07:46:51.407802 20309 RebuildIndexTask.cpp:160] Processing Modify Operation ���ǒ�172.16.210.2
I20230323 07:46:51.463862 70 RaftPart.cpp:2046] [Port: 9780, Space: 32, Part: 38] Send heartbeat
I20230323 07:46:51.679363 73 RaftPart.cpp:2046] [Port: 9780, Space: 32, Part: 17] Send heartbeat
I20230323 07:46:51.723338 70 RaftPart.cpp:2046] [Port: 9780, Space: 32, Part: 65] Send heartbeat
I20230323 07:46:51.732000 71 RaftPart.cpp:2046] [Port: 9780, Space: 32, Part: 15] Send heartbeat
I20230323 07:46:51.811508 72 RaftPart.cpp:2046] [Port: 9780, Space: 32, Part: 55] Send heartbeat
I20230323 07:46:51.907516 73 RaftPart.cpp:2046] [Port: 9780, Space: 32, Part: 96] Send heartbeat
I20230323 07:46:51.950739 71 RaftPart.cpp:2046] [Port: 9780, Space: 32, Part: 42] Send heartbeat
I20230323 07:46:52.073124 20309 RebuildIndexTask.cpp:164] Processing Delete Operation �1248516801073194
暂时找不到有用的日志 
同一个space之内的job是串行执行的. 至于慢, 可能跟环境里的日志很大有关, 你查查日志级别吧.
1 个赞
查了一下日志级别，因该是日志级别太低的问题。但stop掉重建索引的job之后再次重建会失败这个问题也很严重
你试下重启下meta, stop再重建这个操作应该是被完整测试过, 不排除是你之前系统太慢. 立刻报错时的日志里有说啥吗
没有，目前可以很稳定的复现
贴一下浮现步骤哈，目前就是先写入一部分数据，大概20w个点左右的样子。然后再写入的过程中创建2个tag索引和一个边索引，在studio上依次点击索引重建。然后等待带大概六七秒的样子，因为日志级别是0，所以这个时候索引重建大概率是完不成的，然后stop掉最先入队的job，会发现后面的两个重建索引job会直接失败
然后不管是命令行还是studio上重建索引都是直接失败
麻烦你grep “AdminTaskManager” storage日志, 我再看下. 我这周看到了一个类似问题, 但和你这里描述的不一样job compact stuck, 那边是有重启的, 你这应该是没有, 但问题本质可能类似
BTW, 你可以先建好索引, 再导入数据, 就不用rebuild了. 不过日志还是可以给我们分析下, 看看问题出在哪里
先建好索引解决不了问题，因为预知不了所有需要的索引。
日志的话回头我再复现一次贴一下吧