- nebula 版本：3.1.0社区版
- 部署方式： 分布式
- 安装方式： Docker （K8S）
- 是否上生产环境： N
- 硬件信息
- 磁盘 数据盘非SSD
- storage k8s的yaml配置中，磁盘分配500G
- metad k8s的yaml配置中，PVC配置分配500G
- CPU、内存信息
- storage k8s的yaml配置中，单个pod CPU分配3个物理核，8G内存
- metad k8s的yaml配置中，CPU分配4个物理核，10G内存
- graphd k8s的yaml配置中，CPU分配4个物理核，16G内存
- 副本数： storage 3个副本，metad 1个副本，graphd 1个副本
- 磁盘 数据盘非SSD
- 问题的具体描述
- 问题：串行查询时，平均响应时间是30ms，然后我起的并发查询数量越多，响应时间越长，比如，我起的并发查询是20个时，平均响应时间是230ms， 并发查询30个时，平均响应时间是343.9ms
- 疑惑：我的感觉是，在服务端查询的时候，实际上只起了3个线程进行查询，因此客户端并发数越大，平均响应时间越长。我把graphd的yaml中分配的CPU核数增加、内存增加，对响应时间没影响，且通过k8s命令kubectl top pods nebula-graphd-0 来看，CPU 仅为192m（连一个实际CPU的量都不到），MEMORY也只有600Mi。在graphd中，num_worker_threads=0, num_netio_threads=0，请问是哪里出了问题
你可以再看看storage的cpu和内存. (因为你只给storage分配了3个核, 当瓶颈在storage时, 可能就和你感觉只起了3个线程一样)
BTW, meta不用单独分配核, 可以和其他共用, 或者1个核, graph + storage可以调大点
你好，我把storage和graphd的内存、核分配多点实测也没用，而且kubectl top pods | grep nebula来看，storage和graphd的CPU和内存量，也并没有达到瓶颈。
可能的原因点：
- 并发压测时，不同的 query touch 到的数据量有差异，存在某些大 query 导致执行时间变长进而阻塞了部分线程；
- 客户端的并发已经超过服务端能处理的能力，出现的请求排队的现象，比如上述中 graph server 的 worker 线程有 4 个，但是并发有 20 个，那么这 20个并发共用 4个 worker 线程，但是从 cpu 使用率上看不像是这个问题；
- k8s PVC 网络 io 阻塞了请求的处理，不知道环境中的 PVC 是使用的网络存储还是 local persistent volume，如果是网络存储看看 network io 是否有什么限制？
多启动几个 Graphd 试试呢？
谢谢。
关于第一点，应该不存在，因为不存在超级节点，节点的边我有处理。
第二点，应该也不是，因为CPU的使用量远远没有达到瓶颈。
第三点，我去看看
anyway, 非常感谢
好的，我试一下，谢谢