drop space影响查询服务

nebula 版本:3.2.0
部署方式:分布式 :3台节点:graph,storage,meta *3
安装方式:RPM
是否为线上版本:Y
硬件信息
磁盘:SSD

最近在对nebula图库进行压测,发现发一个问题:

首先使用多线程对图库中的某个图(简称为图A)进行并发查询。
然后在压测的某个时间点,我执行了drop space 的操作,将图B进行了删除,随即发现我的压测进程都阻塞了,这期间没有对图库产生任何访问,但重启这些进程之后,又能恢复访问了。

之前部署的线上服务,还出现过一次类似情况,就是drop space后,阻塞了在线的一些查询请求,大概持续了10min。

请问这个现象是什么原因造成的?
为什么删除图库中图B,会对图A的查询请求产生影响?
我看nebula_storage文件夹,不同图库之间的存储位置都是不一致的,按理说不会相互影响才对。

应该是锁导致的,这块应该需要优化。

感谢大佬解惑,请问优化的话,该怎么去实现呢?有什么参数可以设置吗?

目前对space的管理以及内部part的管理都是用读写锁来做并发控制的,所以删除或新增space都会影响当前query的并发效率,所以最好避免这样的操作。

嗯嗯,明白了大佬。但是有个疑问,如果不执行删除space的话,那么图库里面会存在很多无用的旧图,久而久之就会把磁盘给占满怎么办…

能把描述的详细一些吗?
比如:

  1. drop space 的命令是立即返回还是阻塞了一会返回。
  2. 你说的 10min 停顿是在 drop space 后返回后才开始的吗?
  3. 能贴一下 storaged 对于删除 space 的前后日志吗?可以 grep 'has been removed!' 相关字样。

1.drop space的命令是立即返回的,没有阻塞。
2.返回后开始的。
3.storage日志可以看看这个帖子,就是我提到的请求阻塞的情况:DROP SPACE导致服务不可用

在你那个帖子里 Drop Space 停顿几秒是有可能的:现在单机上的所有 space 共享一把大读写锁。我们来看一下这个能不能拆把。

但是停顿 10min 确实有问题,不过估计是数据量太大,然后用的 HDD,可能会删的时间比较长,导致持锁时间长。

1 个赞