Docker编译源码安装

[applausewow]

• nebula 版本：3.8.0
• 部署方式： 分布式
• 安装方式：源码编译 / Docker
• 是否上生产环境：Y
• 硬件信息
  • 磁盘（ 统一分配资源-虚拟机）
  • CPU、内存信息 （16C 64GB *2台 32C 128GB *1 台）
• 问题的具体描述

1. 问题1
   

   
   
   为什么最后容器内编译后能够在宿主机使用？并没有挂载吧？并且环境也不同

2. 问题2

最近节点和连边都已经达到了1~2亿，match一些简单的1跳或者2条很慢，经常RPC超时返回错误，甚至storaged挂掉，大佬们有什么部署建议吗？（资源见上面三台配置）

[MuYi-方扬]

磁盘是 HDD？

[applausewow]

是SSD，不过分配的是虚拟机，不知道虚拟化有多大影响

[MuYi-方扬]

你的简单的 1 跳 2 跳的语句能否发下是怎样的？有的1 跳2 跳的查询其实也挺复杂的

[applausewow]

不好意思，之前没有看到邮件，最近比较忙给耽误了。
其实也就是普通的一二跳，类似于 match (n:type1)-[e:e_type1]-(v:type2) return n, e, v
或者 match (n:type1)-[e1:e_type1]-(v:type2)-[e2:e_type2]-(r:type3) return e1, e2
之前测试发现从100~100w+数据规模查询，只要模式一样，console的执行完成时间都是差不多一致的，但是返回响应的数据时间有很大的时间，所以很多时候是因为rpc的数据传输导致的时间慢或者超过内存而挂掉或者RPC请求超时吗？（检索时间之和模式有关和数据规模关系不大？）
如果是这样是否哪里能够修改rpc的超时时间和传输的数据大小（之前grpc开发时发现需要调整传输数据的size）

[MuYi-方扬]

@applausewow

如果是这样是否哪里能够修改rpc的超时时间和传输的数据大小（之前grpc开发时发现需要调整传输数据的size）

你这“简单”的一跳、二跳并不简单。要全图扫描了。

[applausewow]

是的，确实不算简单，例子举得不太对，但是是否确实由于传输数据过大也会导致超时呢？我想修改rpc传输数据大小和超时的参数
这是我用的ngql：

match (v:user)<-[e:user_follower_user1…2]-(v2:user) where id(v) in [‘xxxx’] with distinct v, v2, v2.user.followers_count as count order by count desc limit 250 match (v)<-[e:user_follower_user1…2]-(v2) return v2, e union match (v:user)-[e:user_follower_user1…2]->(v2:user) where id(v) in [‘xxxxx’] with distinct v, v2, v2.user.followers_count as count order by count desc limit 250 match (v)-[e:user_follower_user1…2]->(v2) return v2, e;