num_accept_threads参数的含义

提问参考模版:

  • nebula 版本:1.0
  • 部署方式(分布式 / 单机 / Docker / DBaaS):分布式
  • 硬件信息
    • 磁盘( 推荐使用 SSD)SSD
    • CPU、内存信息
  • 问题的具体描述

由于有大量查询的需求,想尽可能的提高查询的并发度,想问下:
num_accept_threads这个参数的具体的含义,官网给的解释是“接受进入连接的线程数”,没明白。是指java-client的AsyncGraphClient.class或者GraphClient.class链接grpahd的线程数?那为什么默认值是1呢,只有一个线程能链接吗?

调节num_accept_threads可以提高并发度吗?
还有num_worker_threads这个参数,是否可以提高并发度?

num_accept_threads会影响新建连接.thrift是accept thread接收到连接之后,交给worker线程去处理的(num_worker_threads).

没明白你的意思
num_accept_threads 为什么默认值是1,,,,可以配置其他值吗?其含义是?

@monadbobo
没明白你的意思
num_accept_threads 为什么默认值是1,,,,可以配置其他值吗?其含义是?

num_accept_threads 这个参数你不需要做任何修改,假如你是要性能调优,你可以关注下graphd这两个参数,num_netio_threads, num_worker_threads 现在默认就是按照cpu数的。

单机部署的nebula,在进行高并发查询测试时,发现CPU利用率很低,CPU利用率不到100%(测试物理机有24核),您说的上面两个参数都已经调成CPU的个数,但是似乎没有生效,请问这正常吗

你是怎么个测试过程,客户端并发是多少,query又是怎样的?

使用jmeter压测工具进行测试的,其中用到了studio进行中转请求,并发分别测试了10,50,100,query语句是最短路径查询:find shortest path from id1 to id2 over * upto 5 steps | limit 1000; 客户端并发数上来了,但是单机的CPU利用率没有上升。

你这个测试query应该会扎堆在同个partition做排队,你可以看下磁盘使用情况,还有用perf 看下graph和stoarge的系统调用情况。

好的,我先看下,如果是这样的话,请问应该如何调整呢

浙ICP备20010487号