VSCC20 总结

我们输了,但也看到了差距

如果Harry Chen的后继者没能继续记录ISC ASC SC等比赛的比赛实况,这或许是一个好地方去报点"后Harry时代"比赛的流水账。、

TL;DR

Azure Cyclecloud 能很好的scale 你想干的任何计算,但我们在超过3000W的机器上没有很多经验,也许我在实习的时候有,但也只是对开着的集群运维,我并不那么善于精确的计算cost,在我们队里也似乎没有其他对弹性部署的机器有很好的理解。在写final arch的时候,我们带着以前的思路,由于预算限制导致的想着在任何时候用同样的价格。但云上比赛最好是用最好的机器跑最需要的应用。比如CESM需要HB120rs,那就新开一个机器。比赛之前我们只是把所有编译好的程序放到了一直开着的自带备份xfs的NFS上,pbs、grafana稍稍能用,后来开的机器懒就不配了,也没写脚本,吐槽下cyclecloud这个垃圾前端,还有HPC选项只有ubuntu18.04 和 rhel7。之后还配了个lustre template尝试跑IO500,可是性能不如单盘就放弃了。

如果说SC比赛是一个智商检测器,可以说是在中美贸易战的背景下,测试中国最高学府所能到达的最高点。也确实,三个应用其中两个:CESM、Gromacs都是需要学校背景支持的,清北作为一所能在短时间内集结所有题目的相关老师,并给出建设性建议,不愧为中国最高学府。IO500,RUNJI 宝宝在比赛前4个月左右开始写了一个为之量身定做的一个线性叠加IO性能的库MadFS。我们本来的研判是这只是一个burst cache 能减少memory最后flush cache的时间。但实际上RDMA可以做更好的scalability。据我猜测,他们用了8node L80s

几个比赛以后的反省:PBS scheduler 可以说一点卵用都没有。Azure上之前选用的机器是带SRIOV的,大概也只有之前玩过Exsi的人会吧,驱动安装走了点坑。最后安装的顺序只能是先编译网卡驱动,然后显卡驱动。显卡驱动会破坏ib的安装过程。这块之前写过脚本cloud-init就好了。作为队长,主控权由于我的状态原因,全权由殷老师管理。让我们丧失了一定的灵动性。

这次学校给我们提供了H1-306,可以说是图信的大本营,可以网络直出上海,而且没有限速。可以说很爽了,但比赛第二天下午开始还是各种不稳定,双十一剁手,跨洋剁手也不少。Azure的服务器在德州奥斯丁,而SC使用的zoom服务器在美国,我们的联络人是一个中东裔llbl实验室的computation physicist Axel Huebl,和HPC方向基本一致。

刚开始我们就跑了HPL和60s的HPCG以及IO500,用的英伟达[email protected][email protected]版本的binary,这里有个坑是HPL的binary一旦多于2node8卡就会segfault,而HPCG是不会的,这个坑知道多天以后我们才发现,由于我们从未在多于8卡的机器上跑过benchmark,这个坑算是踩中了。开始的结果不是很理想前者20左右后者800G,IO500随便组个raid0 就到了20,由于选择是8xP100,主办方又有后续不能改机型的规则。其他队都很鸡贼的不说具体时间选择的具体机型,我们老老实实列了我们仅需的机器,并没有为之考虑很多,同时也为预算考虑了很久,毕竟到比赛开始前我还一直以为比赛金额是2500USD。这时候看其他队HPL HPCG都爆70了,我们才知道之前设计时的信息不对称。于是考虑最后再尝试32台P100充分,这理论算力160TFLOPS和4TFLOPS,到这个时间点感觉稳了。指导老师殷老师叫我们稳一手,最后才交成绩。而HPCG需要跑3600s,所以这时候的成绩不合法。

第一天早上10点有个奇怪的考试,CA2.在那之前我也仅仅按照机器配好5台机器2xp100 2x hb60rs 1x d96as,跑完benchmark,刚看了看cesm的测试案例。由于我队友都不怎么会运维。到我们1点回来的时候居然所有机器都是空载的!空载的!啊这,不知道他们怎么想的,就是怕我回来之前他们配不完,应该关掉的。多烧了大约两三百🔪吧。不过这时候,本以为第二天才发的神秘应用minivive的所有脚本柳煜辰弄的都可以跑了,要花的时间也可控,不过可惜的是它只能开2的倍数的线程,而我们的机器是60核的,所以很长一段时间我们都是半载(不能改机器)。吴天元和徐开元负责的gromacs也大致能在GPU上跑了。可这个gromacs的testcase弄的挺恶心的,我们训练的时候发现及时用很大,几十兆大小的蛋白,都不需要很久。所以我们预计给gromacs的时间是不多的,可事实是gpu到第三天还在跑gromacs,是testcase 同一个蛋白要跑几百次,最后出一个趋势图。而且他还要求CPU也要有一半,gromacs是不支持多node的,所以一个算例往往要占一个node好几个小时。

回来以后,我的状态其实不是很好,由于之前一天刚check完通宵了2天写网络project,同时前一天还在负责场地啥的。CA考试就基本糊过去了。cesm是早有一份配置好编译器的环境,脚本提交了task2,和task3。3很快的能跑起来,同时也得到了结果,第一天晚上我也写了一个python轮询调度器,task3跑完跑2,2跑完跑1,1跑完跑4。早上起来的时候2和3都跑完了。可我队友起来的时候告诉我,他手动把一年的算例改成一个月了,跑的不作数,同时他用task脚本,把我跑出来一个月的结果给overwrite掉了,我人傻了。不过一个月还好。我看着有四个node还在跑1和5。后来发现1和5是个zombie程序。搞这些有的没的花了将近大半天时间,到下午4点左右我们才上正轨,跑完了3。这是我们发现之前能编译和跑的task1和5莫名出现了fortrl segfault 退出代码174。Harry的博客提到过这个报错,我们在尝试了ulimit、/etc/security/limit.conf、关selinux、换机器之后,还是没能解决这个问题。我欲哭无泪,第二天晚上就把该关的机器关了,让我队友重新编译了一份,剩下跑其他应用。这是柳煜辰已经整完了一份能自动配置新机器user的脚本。

第三天早上起来以后,队友还是用的intel编译器,不同版本编译的,我开始跑起来总是那个segfault。我尝试在google找遍了所有方法。调到4点钟左右,也就是还剩14小时,我们也没能找到办法,也就放弃了剩下的,这时北大已经交满了所有算例。可能唯一的方法就是换gnu编译器重新编译吧。这时,组委会发了条通知,多加500USD预算,THU杰哥 在下面评论了一句:“Thanks, it's very helpful.” az。

最后一晚,天元回去睡了,他们跑了一部分的task3的gromacs,可是最终算例太大,跑不完了,貌似钱也不太够,也相继放弃了。我是晚上才起来,起来时唯一还对cesm有点念想,最后还是放弃了。还有6小时的时候,我们4位开始了紧张刺激的冲benchmark行为。

NFS在装OMED驱动的时候挂过一次,stale handle detected。我们重启了一遍pbs集群,nfs集群。还好数据都在,我们相继在那个时候用azcopy上传了所有已有结果,发现了60sHPCG结果并不合法。殷老师脸色铁青。32个机器,用pipeline装机器的方法我们花了2个多小时才搞完。然后又花了1个小时弄openmpi的各种问题。最后没能在1小时之内再跑一次HPCG。预算也要抄了,我们只得关掉开的32台P100,回去睡觉了。本次比赛我们和清华的差距就是我们benchmark 没跑完。以及CESM没跑完。