nebula负载Load高,CPU高

  • nebula 版本:v3.0.0
  • 部署方式:单机docker-compose,metad3,storaged3,graphd*3
  • 安装方式:docker
  • 是否上生产环境:N
  • 操作系统:centos7 amd 64
  • 硬件信息
    • CPU*16+Mem 32GB
  • 问题的具体描述
    运行在测试环境下,经常发现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进程占用大量的资源时,我可以通过什么方式知道它正在执行什么工作?

有可能是compaction操作在做压缩

:thinking: 据我所知目前是不支持的,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发送停止的信号

嗯嗯,不过建议你可以先升级到3.6看看。或许很多问题已经解决了

此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。