graphd与metad之间的心跳数据包极大

nebula graph的版本是2.5.0

下图,graphd与metad之间的心跳的数据包很大这是合理现象吗?如果graphd数量很多,会导致与metad leader的之间通信占用很大的带宽

感觉 是在传送数据啊, 心跳包 不会这么频繁的, 这个时刻有做什么操作吗

所以心跳包会是什么样子的。我们集群因为有问题,昨天晚上就将流量切断了,所以根本没有外部流量进来,同时又重启了一下之后,今天早上发现metad的data超过了150g,而昨晚可能只有几个G,而且不停在磁盘读写,wal直接占了90%,线上抓包就看到这些通信。因为没有外部接入,所以可以确定没有在执行某个具体的操作,也没有job,所以我只能认为是心跳。metad的流量超过100mbqs,令人难以理解。下掉了6台graphd(总共10台),metad流量下降90%

下掉的6台graphd中有两台配置metad地址存在错配,各存在一个ip地址不正确(共5台metad)

可以帮忙 把 graph 的 日志发一下吗 log/nebula-graph.ERROR 和 log/nebula-graph.INFO 的

这是nebula-graphd.INFO
感觉昨晚拉起这个服务的服务就不太对劲
Init sessin manager failed: Load sessions from meta failed.

nebula-metad.ERROR

唔 我先插个眼 我判断是和session有很大关系 否则meta不会出现这么大的写入 不过有几个地方有点疑问:

  1. 下面这句话没太看懂,首先为啥有5台meta,配错了是指啥?下线了流量降下去还挺诡异的。最好描述清楚点部署方式

下掉的6台graphd中有两台配置metad地址存在错配,各存在一个ip地址不正确(共5台metad)

  1. 下线之后 其他的机器正常吗?我看13:00左右也还有几十M的流量,这个也有点离谱,你session是怎么用的

99%和心跳没关系,明显是线上读写的中间哪里出了问题

2 个赞

wal里面的确都是session有关的内容,跟session_idle_timeout_secs配置有关吗,我们这个值是0?部署方式是10graphd+5metad+5storaged,流量是很离谱,客户端创建session是getSession(String userName, String password, boolean reconnect) reconnect为true

配错指的是graphd访问的meta address ip,因为容器部署,有台metad中途飘走了,导致ip变更,有两台graphd没有更新过

然后每次query都要新申请一个session吗?还是一个session进行多次复用

复用的,但量比较大,会创建很多个session进行复用,可能有数百个。出现奇怪的现象时我们已经停止调用了,所以没有外部流量访问graphd。停服是为了解决metad ip变化的事情

@steam 得找下session这块熟的同学看看 我已经尽力了

出现奇怪的现象时我们已经停止调用了,所以没有外部流量访问graphd。

然后这个时候流量还是非常高是吗

1 个赞

是的,非常高,全部是是graphd与metad之间的通信,wal大量的写入,打开wal里面全是两边的ip和__session__这样的东西(我们只是简单打开来看看,所以没有管具体是什么含义)。刚才我们将graphd的session_idle_timeout_secs设置60s,顺便改了一下client_idle_timeout_secs和num_netio_threads,将所有graphd关闭并重启之后整个服务看起来就正常了(还未经过严格验证,但指标正确了)

下面是一台metad容器上的部分监控



因为session的缘故进行无止境的写操作是有点奇怪的事情,尤其是在metad上,写操作太多影响很大

是 1 个 graph 有数百个 session 么?然后之前 session idle 的时间是默认的 0?
graph 会周期汇报 session 的状态,但是这么大的流量也不太合理。

还有个推测是,你们的应用端会不会没有正确的 release session,然后因为服务端的 idle 是 0,这些 session 其实在服务端一直都下不掉。

翻了下代码 应该是跟定期上报session有关 可以看下楼上说的session有没有释放

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