scql

scql copied to clipboard

经过对scql的测试发现在量级达到几十万后，经常会出现卡在某个算子无法运行完的情况，如下图所示： 中间结果量级为50w，sort算子无法运行完成（已运行了十几个小时） 且整个过程中未发现cpu/内存/带宽的瓶颈，事实上这几项都消耗的很少，所以像是莫名其妙的阻塞了

请问针对这种现象有没有什么建议？如何能够最大化的发挥机器的性能？

可以补充一下，测试的机器配置是怎样的吗，以及网络带宽和延迟？

可以补充一下，测试的机器配置是怎样的吗，以及网络带宽和延迟？

内网环境，带宽有万兆，延时可以认为基本没有，32核CPU，128G内存

@tongke6

在这种数据规模，以及机器和网络情况下，运行十几个小时没有响应是不正常的。

可以提供更多的信息，以方便我们复现下问题吗？

BTW，上面的截图是其中一方的日志，另一方的日志方便也贴一下吗？

另一方基本上也是一模一样的，这两边在日志上基本没什么区别

事实上我后来看了下代码以后在engine的gflags.conf里加了个参数--link_throttle_window_size=0，大概十几分钟可以跑出结果了 @tongke6

不加这个配置，这个值就是 16，改成 0 后，会使用 yacl 的默认配置，值为 10

那就很奇怪了，难道10反而会比16好？我这边的现象是配成0以后带宽可以上去了，然后跟着cpu也可以上去

在局域网环境下，我们一直都是默认 16 跑没出现过这个问题。我怀疑是内核参数的问题，导致某个地方卡主了。

你所在的环境的操作系统，以及内核版本信息方便提供吗？

我是用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

@shenpeilin 请问下，你们用的什么 MPC 协议，以及你们使用的是我们的官方镜像（用的哪个版本？）还是你们自己用代码编译的镜像？

协议是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++的排查没有什么经验。

方便请教下你们使用cheetah协议的原因吗？相较于semi2k协议，cheetah的性能会慢不少，在测试覆盖上也没有那么全面。 大数据量下cheetah确实不排除存在死锁的bug，需要进一步去复现排查下。

我看你们文档里写，semi2k不是特别安全？ @jingshi-ant

生产上semi2k建议配合 TTP in TEE来使用，cheetah的话，我刚刚基于最新代码本地尝试复现，但100w的groupby没出现卡死。 和spu同学确认，cheetah于近期修复了throttle window的死锁问题以及大数据量切片卡死的问题。 建议：修改spu的依赖编译新的镜像；或者等我们4月中的更新~

“修改spu的依赖编译新的镜像”这一步，可以具体讲一下怎么操作吗？bazel我也没用过，一时半会儿看不出来应该改哪里。

@jingshi-ant

简略步骤如下，供参考~： 1.修改engine/bazel/engine_deps.bzl中的spulib，例如可以将tag 0.7.0b0改为最新的0.9.0dev20240321 同步修改prefix、sha256等字段 2.编译新镜像：bash docker/build.sh -c 3.更新docker-compose.yml文件，修改指定新的镜像，并重新拉起container

因为版本跨度大，实际编译中可能会遇到各类问题，也可以试试更旧一点的tag：0.8.0b0

0.8.0b0好像也编不过 @jingshi-ant

我刚刚从2月的版本开始试了几个，也是有编译问题无法编译成功。。 是否可以考虑下短期先使用semi2k来串流程？验证阶段再升级下我们4月份的版本，确认cheetah的fix效果~ （实在业务紧急的话，也有我们提供fix的镜像之类的方式，但这些都有安全流程要走，比较繁琐）

嗯，我这边没什么问题，暂时没有特别紧急

@jingshi-ant 请问新版的镜像有明确的计划发布时间了吗？

现在的latest镜像已经更新了~（配置项有变动，直接在老环境升级可能run不起来） stable以及0.6.0的镜像预计月中发布

@jingshi-ant 月中好像也没有几天了，没有办法给出一个比较明确的日期吗？

hey@shenpeilin 因为内部会走测试和安全审查，过程时间无法控制，所以具体日期不能准确给出。 如果不出意外的话预计15到20号之间，发布后会同步issue，敬请期待～

@shenpeilin 1.6的版本已经发布了，对应的镜像也更新到dockerhub中了，知悉~ https://github.com/secretflow/scql/releases/tag/0.6.0b1

Stale issue message. Please comment to remove stale tag. Otherwise this issue will be closed soon.