nebula 版本 3.1.0
使用spark-connector读取nebula数据，修改参数max_allowed_query_size=4194304000 未生效
修改配置文件，然后重启服务，重新读取数据
错误 Query is too large (4228576 > 4194304).错误
先改一个小一点的值，排除是过大 invalid 被忽略了，其次，贴一下配置，你是不是少了 --
--max_allowed_query_size=123
再次，这个是 graphd 的配置，没改错对吧？
1 个赞
嗯嗯，或者减一试试
减的没有测试，我有方向可以排查吗
下午把集群空出来专门做的测试，现在是服务状态，不能测试了，减的要明天了，10倍是没有生效的
配置的话如果写的对，文件里不生效要么是值无效、要么是有其他地方写了同一个配置被 override，进程启动的 cmd args 优先于配置文件，不过你是二进制包安装的话这个可能性是没有的，你试试 + 1，或者 x 2 呢，不一定在生产上测试。
嗯，参数我已经改好了，有什么nql可以直接测试吗
如果 +1/x 2 是有效的，就说明之前的配置不生效是因为 x10 的值无效，所以 fallback 到了默认值，问题在于值而不是修改配置的方式。
这样你就可以继续用 spark 根据 x2 了的 query size 往下走了吧
参数改了，除了跑之前的spark任务，有其他的方法可以测试吗，参数是否有效还没测啊
curl 检查 web port /flags 就是最小的检测进程内存里 config 的方法，和你之前的方式一样
1 个赞
curl 里面信息和配置信息一直都是一样的
我测试10 curl 出来的也是10 ，但是spark程序得到的限制是4194304
现在配置改为+1 ，curl结果一致，不能说明生效啦，没有通过spark测试（写出的集群在做rebuild index），想问下有其他nql直接出来这个问题吗
上面是
10 ，星号变格式了
ok，我理解错了你的问题，我以为你配置了 4194304000 但是 query flag 是 41943040
使用spark-connector读取nebula数据
实际上，当我们使用 spark 读取数据的时候，通常是分析型的任务，虽然 spark connector 支持通过 GraphD(nGQL）去读数据，但是比较 scale 的方式是绕过 graphd 直接通过 storage 去扫数据。
你超过 max_allowed_query_size 的原因是写了超级长的 vid list 么？还是？如果能够使用 storage client 去扫描是最好的。
此外
请问这个时候 querl flags 是 4194304 还是 4194304000？
问题一：你超过 max_allowed_query_size 的原因是写了超级长的 vid list 么？
我不确定是读还是写导致的，我用spark-connector是用来同步两个集群的数据的，同时有读写
storage client也可以用来同步两个集群的数据吗
问题二：这个时候 querl flags 是 4194304 还是 4194304000？
4194304000，和配置文件里面一样的，但是spark在同步的时候显示的4194304
明白了，同步的话写入部分一定是走 graphd 的，感觉这里可以调节一下 batch size，小步快跑哈，nebula to nebula 的读我记得是走 storage 的吧 cc @nicole
第二个问题如果能确定我们修改的 graphd 是 spark 连的同一个 graphd 的话，这里可能是有 bug，回头我看下代码哈
现在有两个集群，读取c1的数据写入c2 ,我修改的参数是c1的，看到query想当然认为成读取的设置了，所以我修改c2 参数应该是可以生效的吧 
我的并行数是按照space的分区设置的 60 ，我不太清楚session数量是怎么来的，spark每个task会生成一个吗，并且不会复用session
关于batchsize设置我做过以下尝试
采用默认300的session数量，session数量超出
修改为3000后，session也会超出（task的session没有释放掉，一直累加）
会话数量改为3000，会话有效期改为1分钟，正常运行
以上batchsize为1000，修改batchsize为100 后，出现了连接异常的问题（没有截图，日志已经被覆盖了），batch 减小会增加client的负担吧
1 个赞
贴一下你的代码先，看用的哪个功能。
1 个赞
session 是另一个问题，可以升级新版本的 spark connector，我记得是之前版本里 session release 的 bug 造成的