king
1
nebula graph使用3.6.0版本，java client sdk使用的是3.5.0版本，已知情况：
1.nebula集群中，查询节点graph一共有五台；
2.应用服务一共六台，服务启动时初始化两个SessionPool，每个有300个连接；服务关闭时调用SessionPool.close();
今天在重启其中一台应用服务时，发现了一个诡异的现象：
在重启过程中，其余五台应用服务的查询耗时都发生巨大波动（从几十ms，波动至几百ms），分析耗时波动的查询日志，发现代表服务侧执行耗时的：ResultSet.latency几乎无波动；
再一进步分析日志，发现这些波动均发生在服务关闭时，调用代码SessionPool.close()时的同一秒内；
也就意味着，session的关闭会造成正常查询请求的耗时巨大波动吗？
另外：观察同期nebula集群的CPU监控，未发现明显波动；
ianhe
2
应该是短时间 session 的高并发操作引起的
我们之前有一个服务也是会碰到短时间高并发的请求和关闭 session，不仅仅是查询时间会变长，连 session 的请求和关闭时间也成倍的增加了，后来经过优化，减少并发量后性能就保持平稳了
king
3
看了SessionPool.close()的代码，实际上就是一个for循环，不带sleep时间间隔，单线程循环close session，这也能影响那么大吗？
唯一能改进的就是重写SessionPool.close()函数，for循环中加个sleep间隔？
ianhe
5
这种情况采用自己管理 sesison 池的方式或许更好，并且在 session 销毁的时候分批销毁，中间间隔几秒钟把 tps 降低至。我之前的情况是tps在500左右，降到100以内就基本没问题了。