特征数量对求交速度的影响
T-ze-yu opened this issue · 31 comments
我使用p2p模式的kuscia API进行了求交测试，其中100W与100w求交没有特征只有标签y，31S就搞定了，然而50w与50w求交各450维特征，却要7分多，很明显原始数据的特征数量会影响求交的速度，而按逻辑求交只是索引间的计算，这是为什么呢？
请问有日志可以看到PSI实际运行的时间吗？
应该是可以的，我再跑下
嗯现在卡这了
麻烦重新上传一下日志截图，感谢！
现在已经跑完了
现在看一下50w求交的新日志，应该是可以了
应该就是卡在这个位置，原始图片我现在也找不到了，如果要再看，我这边也是可以复现的。
卡在 perfetto.cc 这句吗？
是的
嗯，再确认一下问题数据量是50w，450维数据，就会稳定触发这个问题。
那数据维度减小时，这个问题会缓解吗？
推测来说应该是的，我还做了40W 450维特征的求交测试，看了日志大概也是这个问题：
可以方便测一下 50w 200维特征吗？看一下维度是否存在影响。我们控制一下变量。
好的，稍等
同时麻烦确认一下secretflow的版本。感谢！
50w 200维特的日志卡这10几分钟了，不知道是不是因为任务跑太多，机器资源下降了
但好像空闲的资源又蛮多的
好的 我们这几天会处理一下这个问题，感谢你的反馈！
好的，感谢！另外方便补充一个问题吗，关于50w*450维数据求交后做数据分割失败了，下面是日志：
50w-split.log
好的，感谢！另外方便补充一个问题吗，关于50w*450维数据求交后做数据分割失败了，下面是日志： 50w-split.log
看上去像是oom了
是的，但实际内存挺大，并没有用完，一个512G，一个256G。是不是在资源分配上并没有得到足够的内存
是的，但实际内存挺大，并没有用完，一个512G，一个256G。是不是在资源分配上并没有得到足够的内存
关于随机分割oom的问题麻烦在 https://github.com/secretflow/secretpad/issues 这里提问，感觉和算法优化和容器资源分配是有关系的，感谢！
好的，感谢
hi @T-ze-yu
我成功复现了您报告的问题。
经过研究，我发现这并不是一个bug。日志本身带有欺骗性，实际上程序卡住的阶段是正在读取整个csv文件，从中提取出需要使用id列产生hash值并对其进行分桶。由于必须读取整个文件，因此需要消耗大量时间，即使特征值根本没有参与运算。同时最后求交集时，由于标签值比较多，也会消耗更多的时间写入文件。
好的，感谢回复