Category: Entertainment 🤮

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没跑完。