我们项目中match 0…4跳的查询用得比较频繁，例如一条典型的查询如下：
即：统计某个起点四跳内，各种符合条件的节点数；
nebula版本为3.6.0，服务器资源：有三台，8核32g的机器，经常性发现有这么一个现象：
对于1条完全一样的上述查询：在业务高峰期查询latency耗时在100ms+，而低峰期重放该查询，此时耗时往往只要10ms+
高峰期cpu资源达到了70%左右，其他资源排查下来并无明显异常；
尝试过优化参数：num_worker_threads，从8提高到32，似乎没有明显提升；
偶然发现还有这个参数：num_operator_threads，从描述可以提高单条查询的并发度。
目前生产这个参数为默认值2，想尝试提高到和cpu核数一致的8，想请问下对于我的查询是否能有提升呢？
@wey 这个问题困扰大半年，希望百忙中能抽空给予解答！如果无效，还有什么其他办法吗
num_operator_threads 这个应该没用；
业务高峰查询因为 io 读写（磁盘 IO、网络 IO）可能比较高，latency 下降是有可能的。
磁盘 IO 不够的话可以考虑多放几块盘。
网络 IO 不够的话检查下是否是万兆网卡；
非常感谢能够回复！！！
我顺便继续提几个问题：
ResultSet中的latency应该仅包含服务侧耗时吧，服务侧查询队列等待等也在内，不含请求的网络耗时，查到过几个不同的说法，后来看了SessionPool源代码，应该是仅服务侧的所有耗时；
关于耗时波动问题，不仅是高峰期，在低峰期也经常发生：比如我们监控到慢查询后，拿到查询语句在重新执行，latency经常从当时记录显示的 几十甚至上百ms，降低至10ms左右，当时非高峰期，集群的cpu使用率在10%以内；
至于高峰期您说的磁盘 IO和网络IO，从监控上看应该是尚未达到瓶颈的：
此时集群cpu在60%左右，且我们监控的主要是ResultSet中的latency，应该不含网络耗时
非常期待再次回复！！！
你重新执行的时候，数据还是那个数据，起点还是那个起点吗？
不同的点，可能会因为点的出入度不一样，导致查询效率有所区别。
如果发现有慢的，可以 profile 下看具体哪里慢
ps：从业务角度来看，多少算慢啊？
感谢回复！！！
1、我是用的完全一模一样的查询语句ngql，在很短的时间内重新执行来对比耗时；
2、图空间数据没有过期和删除机制，图的数据量和复杂度只会比当时监控到的更大；
3、事后重新执行，耗时从几十上百ms，恢复到10ms以内，再看profile结果应该没多大作用，大概率是资源的问题？
4、我们业务用来做线上实时特征的查询，耗时超过30ms基本就算超时了；
另外我前面问的，Result中的latency，应该是纯服务侧的耗时吧（包括服务侧的排队等待等），已经排除网络相关耗时对吧，我上面所说的耗时都指的是latency
是的，一模一样包括且参数，线上会把超过耗时阈值的自动记录下来，事后定期回放，发现有大量的这种情况发生：当时耗时大几十上百ms，事后回放耗时在10ms以内的。
而从监控看，很多当时集群资源cpu，内存使用率很低的情况；
另外：Result中的latency的定义是我描述的吗，这个问题很重要，我们都是基于这个来判断的，因为客户端记录的excute耗时包含网络等干扰情况；
我再提供一个示例，早上突然间耗时又抖动，查询延迟抖动到秒级（Result中的latency）又快速恢复正常，从监控看cpu，内存等指标都正常，查询的qps也是平缓的没有波动；
而从日志看期间有几十笔都慢了，我抽查了一条语句到控制台手动复查，发现耗时只需要5ms，我提供这条语句的profile记录，也没看出任何异常；
@MuYi-方扬 @wey 两个大佬麻烦帮忙看看，被这个问题困扰了非常久，低峰期常常偶发这种波动，只是高峰期会更加集中（cpu70%+），事后复查耗时几乎都在10ms以内
profile记录：
1000ms.xlsx (12.3 KB)
Result中的latency 和研发确认了下，是服务器时间
咨询下，你这个是虚拟机吧？你的监控是虚拟机的监控吗？是否有宿主机的监控
机器用的是公有云：这是腾讯的cvm，类似于虚拟机
这几个监控时间没对上。话说 cpu 那几个波动是什么？
是这样的：
1、20:00,20:30高峰期必现的高延时和机器监控：
是昨晚20:00,20:30的监控，这两个时间段cpu使用率达到70%，对应的平均查询延时到了50ms+，150ms+
2、今天9点左右的的，查询延时到了几百毫秒到秒级，而机器监控毫无波动，语句抽查只需要耗时5ms，我稍后可以回放这期间全量的查询来排查，之前就这么干过，但是都显示耗时正常；
