- nebula 版本：v3.0.0
- 部署方式：单机docker-compose，metad3，storaged3，graphd*3
- 安装方式：docker
- 是否上生产环境：N
- 操作系统：centos7 amd 64
- 硬件信息
- 问题的具体描述
运行在测试环境下，经常发现CPU暴增，3个storaged进程，总计要占到10几个核心的CPU，1000%多;
查询了SHOW JOBS、SHOW QUERIES，发现个别语句执行时间非常长（几十秒），通过KILL QUERY(SESSION=xx,PLAN=xx) 的方式终止了任务和语句的执行，但CPU依然占用非常高；
初期怀疑查询时占用磁盘io问题，通过iotop，发现storaged进程有时候占用非常大的io，200mb/秒，但有时候io为0，但cpu一直是1000%+
但是在经常静默一段时间后，几分钟或几十分钟，CPU偶然可以降低…根据我的猜测，可能是storaged进程并不支持中断或者kill操作；
我想问的是：我能通过什么方式，知道nebula-storaged进程正在做什么？ 当我发现storaged进程占用大量的资源时，我可以通过什么方式知道它正在执行什么工作？
steam
3
据我所知目前是不支持的，cc @MuYi 我们是不是可以在这块做些监测，看这些进程正在运行什么 job？
是的，根据我的排查结果，它可能在执行复杂的job、巨大的查询语句等，但nebula-storaged并不接受终止任务操作，比如stop job id, kill query(session=x,plan=x)等操作时，它并没有通知到storaged进程(或者storaged不支持终止？)，仅仅在graphd收到了终止操作
这类似于当你请求一个耗时非常长的http请求时，达到了nginx超时界限，返回给了客户端timeout错误，但nginx并不会通知proxy后端的服务，或者无法通知，虽然在客户端看来请求失败了，但真正的请求依然在后端服务中执行。
我目前没有找到可以终止storaged任务的api，或者查看storaged当前工作状态的api，以上都是我的猜测…
1 个赞
这是有可能的，例如多副本恢复的工作也不会在job manger里体现，而实际上storage在后台重建数据，只能通过查询来验证数据完整性。
作为我们自己应用而言，应用间具备一定的协调性是合理的。 请 @MuYi 考虑下graph上的query取消后向storage发送停止的信号
MuYi
7
嗯嗯，不过建议你可以先升级到3.6看看。或许很多问题已经解决了