drop space影响查询服务

问答 问题
1

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

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

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

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

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

1 个赞
2

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

4

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

5

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

6

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

7

能把描述的详细一些吗？
比如：

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

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

9

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

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

1 个赞
10

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