集群环境下二层路径查询性能很不理想

服务器环境配置:
集群部署方式:

机器名称	IP地址	graphd进程数量	storaged进程数量	metad进程数量
A	**.**.**.193	1	1	1
B	**.**.**.199	1	1	1
C	**.**.**.218	1	1	1

A机器配置:
处理器: Intel(R) Xeon(R) Gold 6250 CPU @ 3.90GHz* 32(cores)
内存:376GB
硬盘:959.7 GB SATA
B机器配置:
处理器: Intel(R) Xeon(R) Gold 6250 CPU @ 3.90GHz* 32(cores)
内存:376GB
硬盘:959.7 GB SATA
C机器配置:
处理器: Intel(R) Xeon(R) CPU E7-4850 v2 @ 2.30GHz* 32(cores)
内存:377GB
硬盘:7198.9 GB SATA
客户端环境配置:
处理器: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz * 8(cores)
内存: 15GB
硬盘:365GB SATA
软件配置:
测试的Nebula Graph版本:V2.5.0
数据集介绍
社交图谱数据集:https://github.com/ldbc
LDBC_SNB_SF100
实体情况:8类实体,总数282385585
关系情况:25类关系,总数1775511727
分区情况:24 Partitions
副本情况:1Replica Factors
image

二层子图查询
10、15、20并发下,每个线程进行15分钟测试,此次查询涉及的数据量:261,898,881条
测试脚本
match p=(v:person)-[e:likes_comment|:knows*2]->(v2) where id(v)==tag1 return p | limit 0,10
测试时会随机取peson实体的id来替换上面语句的tag1.
下面以10并发为例,展示相关cpu、内存、网络带宽,磁盘使用情况
A机器:
193
B机器:
199
C机器:
218
10并发情况下的聚合报告:
image

很赞的总结。最后那个统计看不明白,结果的QPS是多少呢?有没有试过手动执行单条查询延时多少?
感觉需要专门做压测的同学来看看。

10并发情况下,该测试案例的tps是0.24,平均响应时间是40.5秒,通过nebula-console执行二层路径查询,随便选择一条测试过程中执行过的NGQL:match p=(v:person)-[e:likes_comment|:knows*2]->(v2) where id(v)==17592186284863 return p | limit 0,10 这个NGQL花费了226秒.

虽然目前match性能略差些,也不至于这么慢,你单条语句那个贴个profile上来看看?

这个只有执行计划,我是指带时间的profile,你就执行:
profile match p=(v:person)-[e:likes_comment|:knows*2]->(v2) where id(v)==17592186284863 return p | limit 0,10



SATA

对哦,是机械硬盘还是SATA接口的SSD?
另外profile的截图中少了3条,从已有的profile看也没有200多秒那么夸张啊。

机械硬盘.第一页重新截图了。

机械硬盘就是很慢的,看你机器内存比较多,可以增大一下 block_cache.
–rocksdb_block_cache 改为内存 1/3 单位 MB。

这样数据预热后,就可以减少从磁盘读。

image
这个是之前storage节点的配置。已经配置很大了。

这页没有profile数据啊 :upside_down_face:


不好意思,不知道为啥之前的滚动截屏没显示这栏数据。

在测试过程中偶尔会发生下面的错误。
match p=(v:person)-[e:likes_comment|:knows*2]->(v2) where id(v)==15393163117874 return p | limit 0,10’, failed: Storage Error: part: 12, error: E_RPC_FAILURE(-3)
218机器的storage节点挂掉了,下面是nebula-storage.ERROR文件的错误日志

match 的性能会在年底的版本有专门的优化,可以关注一下年底的版本

这个match查询路径,能不能用go子句进行替代呢?会不会性能更好点

go语句 无法返回 路径, 只能返回 点或者边,如果业务确定要路径,无法用go替换

@jmq2020 除了机械硬盘storage慢些外,我看他的profile中,有个19w行的Project算子也花了9秒多,比我经验中慢了不少,这个有啥可以优化的地方呢?

1 个赞

在console执行相同语句,时不时就会报类似的错误Storage Error: part: 15, error: E_RPC_FAILURE(-3).感觉不是很稳定,这错误是什么原因引起的?

浙ICP备20010487号