nebula查询查询一段时间后，性能就会下降很厉害

sch15210679032 · 2023 年10 月 9 日 02:04

nebula版本：3.6
服务器配置：8核，16G
nebula查询查询一段时间后，性能就会下降很厉害，从0.1s到2s，数据量没有太大变化，就2万

steam · 2023 年10 月 9 日 02:12

你这个服务配置是完全服务 NebulaGraph 的么？还是说有其他的程序也在跑？也许是其他程序抢占了系统资源导致的速度下降。

此外，“NebulaGraph是针对 NVMe SSD 进行设计和实现的，所有默认参数都是基于 SSD 设备进行调优”，你看下你的机器是不是 HDD 的，是的话，有条件可以换个 SSD 试试。

引用来源：准备资源 - NebulaGraph Database 手册

sch15210679032 · 2023 年10 月 9 日 02:20

这是执行语句，重启后是0.1s

sch15210679032 · 2023 年10 月 9 日 02:22

你指的抢占资源是，我们的是stroage,meta、Graph都在一台机器

sch15210679032 · 2023 年10 月 9 日 02:22

我们的机器是SSD

steam · 2023 年10 月 9 日 02:24

不是 nebula 的服务，我的意思是这台机器还有部署其他不是 nebula，像是 QQ、微信之类的其他应用程序。（因为配置很像一台笔记本的配置，所以循例问下）

sch15210679032 · 2023 年10 月 9 日 02:25

我们是容器化部署，这些配置是准们给这个nebula使用

sch15210679032 · 2023 年10 月 9 日 02:26

对于增量数据是采用mq接收，然后像nebula执行增删改语句同步

steam · 2023 年10 月 9 日 03:08

方便的话看下容器里服务进程的资源占用情况看看呢？看下哪些服务用了服务资源

sch15210679032 · 2023 年10 月 9 日 03:43

欢乐马1 · 2023 年10 月 9 日 03:51

为什么只要重启storaged服务，性能就提升了，这个比较无解，希望官方能给一些排查思路。

steam · 2023 年10 月 9 日 05:41

可能是某些服务占用了系统资源吧。不过，具体还是要看你当时的服务状况。

sch15210679032 · 2023 年10 月 9 日 05:42

这个服务器里只给这个用了

steam · 2023 年10 月 9 日 05:44

这个是不是现在查询 0.1s 的状况？根据你的描述，应该经过一段时间之后，查询同语句会上升到 2s，到时候你记得截图下系统资源的图，看下具体哪些服务用了资源。

sch15210679032 · 2023 年10 月 9 日 05:55

好的

dbacyj · 2023 年10 月 9 日 08:23

可以profile看下执行计划，对比下快慢两次查询具体是在哪一步比较耗时

欢乐马1 · 2023 年10 月 12 日 02:13

基本情况：
nebula 3.5

配置文件如下附件所示
nebula_etc_test.tar.gz (4.8 KB)

机器配置：4C8G(这是找的另一个环境，实际8C32G会是一样的结果）

问题描述：某些match语句在系统运行一段时间后变慢

变慢的查询语句是这样的：

match (v:document) where v.`document`.recycled =="0" and (v.`document`.is_global == 1 or v.`document`.tenant_id=="1632931640315338752") with v
        match (v:document)-[e]-(v2) where 1==1
            and (
                            v2.`ppt`.name == "123" 
            )
        WITH
            v.`document`.class_name as class_name,
            v.`document`.obj_id as obj_id,
            v.`document`.code as code,
            v.`document`.name as name,
            v.`document`.creator as creator,
            v.`document`.last_update as last_update
        ORDER BY last_update desc
    
                RETURN count(*);