Nebula 高可用与性能问题

  • nebula 版本:3.4.1

  • nebula-http-gateway版本:3.4.0

  • 部署方式:分布式

  • 安装方式:RPM

  • 是否上生产环境:Y

  • 硬件信息

    • 磁盘:SSD
    • CPU、内存信息:16c 128G
  • 背景
    1、客户端自己管理session,一个线程一个session
    2、由于nebula-python客户端不支持协程异步调用方式,我们采用了nebula-http-gateway来支持异步查询
    3、未升级3.4.1前,查询会将nebula-graph查到宕机,升级后暂没有遇到宕机问题

  • 现象
    1、模拟nebula-graph宕机场景,我们停了其中一台nebula-graph,session并不会自动删除,导致session容易超过max_sessions_per_ip_per_user限制
    2、模拟nebula-http-gateway宕机场景,重启gateway,session并不会自动删除,升级到3.4.0版本,session可以自动删除
    3、性能问题,session中的查询语句需要排队等待执行;不同session查询同一个起点,也需要等待。

  • 问题:
    1、nebula-graph停止,是否应该关闭已建立的session?
    因为在graph重启之前,客户端关闭是失败的
    2、nebula-python新版本支持协程异步调用了吗?
    3、nebula-http-gateway是否应该增加session维护功能?统一由gateway管理session、分配session
    客户端不好维护session,nebula图库集群节点宕机,客户端并没有收到通知,还用之前的session查询,会报错。
    客户端还需要实现session负载均衡的算法,比如线程忙碌,session忙碌,查询请求堆积,整体响应耗时长。
    4、如何提高并发?
    我这边现有业务量是每秒1000的请求量,目前的想法通过5、6提高session的数量,支持并发查询。
    5、max_sessions_per_ip_per_user有没有最大限制?
    6、nebula-http-gateway限制了最大clientMaxNum=200,应该改成可配置的。

请问下 你在 背景里面第三点描述的,将nebula-graph查到宕机,是指这种报错吗?

过去一周多了,日志没有保留

错误是这个,
StorageAccessExecutor.h:40] GetVerticesExecutor failed, error E_LEADER_CHANGED, part 128

确实也曾遇到相同的问题,版本3.4.1 也是用的nebula3-python

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