我们查询的这个点数据大概20亿，边大概130亿，且对应字段做了索引。使用下面go from 查询时候，查询时间经常超过100秒，
go from ‘e7762e2f7e8d287a87a82cccecf78462’ over resolve REVERSELY where $^.ip.label == ‘ip’ and $$.domain.label==‘domain’ yield $^.ip.label,$^.ip.name,$^.ip.service_provider,$^.ip.ASN,$^.ip.cdn_vendor,$^.ip.is_idc,$^.ip.is_cdn,$^.ip.is_proxy,$^.ip.is_malicious,$^.ip.is_targeted,$^.ip.malicious_type,$^.ip.malicious_family,$^.ip.apt_group,$^.ip.ti_tags,$^.ip.malicious_ports, resolve._src, resolve._dst, resolve._dst as dst, resolve._type, resolve.count,resolve.first_seen,resolve.last_seen,resolve.type,resolve.label, $$.domain.label,$$.domain.name,$$.domain.sld,$$.domain.dynamic,$$.domain.is_malicious,$$.domain.is_targeted,$$.domain.malicious_type,$$.domain.malicious_family,$$.domain.apt_group,$$.domain.is_tpd,$$.domain.ti_tags ,(resolve.last_seen + toString(resolve._dst)) as last_seen| order by $-.last_seen desc | limit 0, 10
go from 查询会使用索引吗。我如何去提升查询效率，使用的nebula 3.8集群
怀疑是查询涉及到的边的数量比较多，你可以 count 下。
从某个点出发的查询是不会用到索引的
确实查询出来的结果应该会有几千上万条，然后再limit 10。这样的话，有没有好的解决方案呢
result.csv (10.0 KB)
这是某一个查询的执行计划，帮忙分析如何解决查询慢的问题，万分感谢
我看执行耗时时长的在某个节点，这是为什么呢。其他节点耗时并不高。这是expandall的输出。
{
ver: 0, rows: 262, execTime: 2572us, totalTime: 152482982us
graphExpandAllTime+2: 2519(us)
resp[0]: {
“exec”: “152478125(us)”,
“host”: “10.252.145.52:9779”,
“storage_detail”: {
“FilterNode”: “2009(us)”,
“GetNeighborsNode”: “2920(us)”,
“HashJoinNode”: “2006(us)”,
“RelNode”: “2920(us)”,
“SingleEdgeNode”: “1902(us)”,
“TagNode”: “90(us)”
},
“total”: “152479787(us)”
}
}
以下是getvertices的profile 输出：
{
ver: 0, rows: 258, execTime: 3099us, totalTime: 108640388us
total_rpc: 108639715(us)
resp[2]: {
“exec”: “1316(us)”,
“host”: “10.52.19.76:9779”,
“total”: “61735(us)”
}
resp[1]: {
“exec”: “108636359(us)”,
“host”: “10.252.145.52:9779”,
“total”: “108638256(us)”
}
resp[0]: {
“exec”: “2516(us)”,
“host”: “10.52.19.74:9779”,
“total”: “3115(us)”
}
resp[3]: {
“exec”: “907(us)”,
“host”: “10.52.19.75:9779”,
“total”: “1356(us)”
}
resp[4]: {
“exec”: “1730(us)”,
“host”: “10.52.19.77:9779”,
“total”: “2671(us)”
}
} 所有节点负载并不高
看下网络吧。从 IP 来看，这个异常的节点和其他几个节点不在一个网段里，估计网络延时比较高导致
[root@nebula01 es-ops]# ping 10.52.19.76
PING 10.52.19.76 (10.52.19.76) 56(84) bytes of data.
64 bytes from 10.52.19.76: icmp_seq=1 ttl=59 time=0.085 ms
64 bytes from 10.52.19.76: icmp_seq=2 ttl=59 time=0.085 ms
从ping上来说和其他节点响应时间几乎一样。另外，麻烦请教下，这个52节点应该是主节点吧，一些监控和console等服务都部署在这个节点上（我自认为是主节点）。nebula查询也会从主节点上通过rpc通信吗。还有个问题需要请教下，我show QUERIES 发现，会有大量running 的insert任务堆积，这个可能原因是什么呢
我这是从52这台机器向其他机器ping的。应该咋ping呢。。请明示
哦哦明白了。
nebula 没有主节点的概念。
如果如你所说，有大量的 insert 任务堆积，也有可能你刚好这个节点上有比较多的 io 操作导致
这几个节点与我们的业务服务器都ping 了下，延迟几乎一样，都在22ms左右。可能是网络问题吗
如果不是网路 io 的问题，可能检查下磁盘 io。这个盘类型和其他盘类型一样吗？
磁盘是一样的，都是ssd,以下分别是52节点和其他某个节点的磁盘信息：
所以，磁盘应该不是问题。网络的话，虽然与客户端ping的延迟都一样，但是52节点的网卡与其他节点的确实不一样。52节点的网卡不支持自动协商，且无法修改成自动协商。以下是52节点和其他节点的网卡信息：
另外，从dashboard中看，网络和磁盘 52节点和其他节点并没有太大的差别。还有什么办法进行排查么
因为 52 节点我理解还经过几层交换机，吞吐量是否能达到那么大不是很确定。比如是否有可能中间交换机的带宽可能没那么大
另外，查看下 leader 的分布是否均匀。
你这个问题是必现的吗?
leader均衡我已经做了, 我尝试了几个profile, 显示是这个节点查询慢。需要再多测试几个得出结论。另外，索引创建的话，也从没成功过，耗时上百秒的查询，几乎都是双向查找的ngql。这样如何优化呢
如果是超级节点的原因，只能使用超截来解决吗。另外，多次出现了一个情况，晚上的时候，某个节点的某块磁盘给写满了，导致storaged异常了。需要删除部分东西释放空间，重启storaged服务磁盘就会降下来。这是为什么呢。这个情况不是某个节点，哪个节点都出现过。基本发生在晚上
