shenpeilin
shenpeilin
> 可以补充一下，测试的机器配置是怎样的吗，以及网络带宽和延迟？ 内网环境，带宽有万兆，延时可以认为基本没有，32核CPU，128G内存 @tongke6
另一方基本上也是一模一样的，这两边在日志上基本没什么区别 事实上我后来看了下代码以后在engine的gflags.conf里加了个参数--link_throttle_window_size=0，大概十几分钟可以跑出结果了 @tongke6
那就很奇怪了，难道10反而会比16好？我这边的现象是配成0以后带宽可以上去了，然后跟着cpu也可以上去
我是用docker部署的，也会受操作系统的影响吗？操作系统的信息如下： LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch Distributor ID: CentOS Description: CentOS Linux release 7.1.1503 (Core) Release: 7.1.1503 Codename: Core 内核:4.18.0
协议是CHEETAH，镜像的话我在2024-01-24拉的secretflow/scql:latest，我觉得应该是0.5.0b2? @tyrone-yu
> 另一方基本上也是一模一样的，这两边在日志上基本没什么区别 > > 事实上我后来看了下代码以后在engine的gflags.conf里加了个参数--link_throttle_window_size=0，大概十几分钟可以跑出结果了 我后来发现加了这个参数以后问题也没有完全解决，部分场景下还是会出现看上去像是跑着跑着就停了的情况。目前已经发现的包括含有avg、case when、count distinct的sql。现象上看很像是死锁，不过我对C++的排查没有什么经验。
我看你们文档里写，semi2k不是特别安全？ @jingshi-ant 
“修改spu的依赖编译新的镜像”这一步，可以具体讲一下怎么操作吗？bazel我也没用过，一时半会儿看不出来应该改哪里。 @jingshi-ant
0.8.0b0好像也编不过 @jingshi-ant 
嗯，我这边没什么问题，暂时没有特别紧急