请问Nebula的慢查询监控应该怎么做

有几点诉求:
1.慢查询监控怎么观察,是否有慢查询日志供使用;
2.慢查询是否有熔断机制,比如配置查询超过多少行就kill掉这个查询,或者运维人员可以手动kill掉某个慢查询

试下这个配置参数 storage_client_timeout_ms


我现在情况是graphd有很多线程跑飞了,截图这些个线程cpu使用率一直100%,抓了堆栈都是在: nebula::graph::GoExecutor::VertexHolder::getDefaultProp(int, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&) const ()

看起来是查询的结果集太大,调整storage_client_timeout_ms后graphd的这些线程会检测出来超时并中断相应的查询么?

storage_client_timeout_ms这个参数无法控制graphd。能否提供一下你的查询语句和数据量?

GO FROM 点ID OVER edge1 REVERSELY YIELD edge1.f1 as edge_f1, edge1.f2 as edge_f2 … , $$.tag1.f1 as tag1_f1, $$.tag1.f2 as tag1_f2 …;
类似这样;
属性信息比较多,有100多个、都在YIELD后要带出来;

业务层想通过上述一条go语句拿到所有信息,但问题是极端case场景下、上述go语句能触达几十万甚至上百万个节点,此时nebula graphd就一直在处理

是否有方法,能:
1.nebula服务端遇到这种慢查询能熔断,比如自动kill这个查询 或者给运维人员入口可kill;
2.这种大查询业务怎么使用,看了LIMIT语句貌似也实现不了,LIMIT的原理是不是把所有数据都捞了一遍然后才开始LIMIT的呢
辛苦

是的,limit语句是在返回的结果集的基础上再进一步的处理。
目前nebula1.0还没有提供直接kill执行线程的接口。如果偶尔出现这个问题,可以通过修改trace_go参数,并在log中进行分析。

好的,感谢

浙ICP备20010487号