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

renhui · 2021 年10 月 22 日 07:56

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

机器名称	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
数据集介绍
社交图谱数据集：Linked Data Benchmark Council · GitHub
LDBC_SNB_SF100
实体情况：8类实体，总数282385585
关系情况：25类关系，总数1775511727
分区情况：24 Partitions
副本情况：1Replica Factors

二层子图查询
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并发情况下的聚合报告：

xjc · 2021 年10 月 23 日 10:35

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

renhui · 2021 年10 月 25 日 07:30

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秒.

xjc · 2021 年10 月 25 日 09:06

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

renhui · 2021 年10 月 25 日 10:36

xjc · 2021 年10 月 25 日 12:59

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

renhui · 2021 年10 月 26 日 01:25

min.wu · 2021 年10 月 27 日 07:22

SATA

xjc · 2021 年10 月 28 日 02:57

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

renhui · 2021 年10 月 28 日 03:35

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

HarrisChu · 2021 年10 月 28 日 04:35

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

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

renhui · 2021 年10 月 28 日 06:04

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

xjc · 2021 年10 月 28 日 07:11

这页没有profile数据啊

renhui · 2021 年10 月 28 日 07:24

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

renhui · 2021 年10 月 29 日 07:22

在测试过程中偶尔会发生下面的错误。
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文件的错误日志

jmq2020 · 2021 年10 月 29 日 07:49

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

renhui · 2021 年10 月 29 日 08:08

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

jmq2020 · 2021 年10 月 29 日 08:30

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

xjc · 2021 年10 月 29 日 09:08

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

renhui · 2021 年10 月 29 日 09:20

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