跳到主内容
EN

打开命令面板

搜索文章、系列、自习室课程或外接设备…

2020 年粤澳计算机程序设计大赛网络赛总结

WeJudgeOnline JudgeACM-ICPC运维技术分享

本文转自我在知乎的回答:如何评价 2020 年粤澳计算机程序设计大赛网络赛?,首发于 2020-04-25(比赛当晚)。

本人 WeJudge 团队技术负责人,人在国内,没坐飞机,不请自来~

今天是 WeJudge 3.0 项目 2018 年立项开发以来,举办过的最大型比赛了!

本次网赛迎来了广东省各大高校的诸多高手同台竞技,充分展示了各位选手的实力。早上 8 时开始,不到 10 分钟,就有 6 题被拿了一血,不到 3 小时,排行榜首过 15 题了!(吐槽一下出题人,怎么出的这么简单 ;-) )截止至晚上 8 时整,共 1196 名同学至少过题一道,有 19 道题被拿一血(总共 20 题,其中 E 题无人过题),排行榜上第一名是来自华南理工大学的郑炜城同学,恭喜!

凡事没有一帆风顺,作为 WeBug 系统(不是),此前花了大量时间在服务端优化上,结果比赛开始的时候,服务端看上去还挺顺的哦。于是顺手点了一下排行榜……嗯?我浏览器怎么卡爆了?经过一个多小时的排查,最终问题定位在了 react-virtualized 组件的 CellMeasurerCache 上,因为没有设置 fixWidth 属性,导致在渲染大量 Cell 的时候,每个 Cell 都去渲染并计算了 Width,2300 * 20 == BOOM,紧急修复后恢复正常。

考虑到是 2000 多人的比赛,我们手上也就只有一台双路 E5 2603 v2,学校借给我们一台单路 E5-1620 v4 作为主服务器,以及三台 E5 2603 v2 的单路服务器作为判题机服务器。根据百度统计的数据估算,短时间内大概在 800 - 900 PV 的时候我们服务器的承受量达到了峰值,接口访问出现也拥塞的情况。但总体来说,除了比赛结束那一瞬间可能有大批人访问排行榜,导致服务器压力过大,接口拥塞 2-3 分钟左右以外,整个比赛期间没有出现大面积崩溃、拥塞的情况,我悬着的一颗心终于放了下来,长舒了一口气。

赛时最近 30 分钟访问情况,20:00 峰值 PV 977 / UV 337

再来看看咱们的各个数据库服务的工作情况。咱们的系统在设计上采用了 MySQL 作为主数据库、Redis 和 MongoDB 作为副数据库和缓存服务,RabbitMQ 作为队列数据库,虽然设计上支持分布式部署,奈何我们没有那么多服务器 _(:з」∠)_ 于是主服务器基本上都是用来承担这个他们的工作了。

这次最佳凉快奖颁给了我们的 MariaDB 同学(也就是 MySQL 的好兄弟),平均不到 20% 的 CPU 占用率,您搁这儿树下泡茶喝咖啡呐?

WeJudge Database Server 的 CPU 占用,平均 1.139%,峰值 11.18%

劳动光荣奖,颁给 Redis 和 MongoDB 同学吧。账号数据、题目数据、排行榜的数据计算和缓存是 Redis 同学负责输出的,MongoDB 同学则负责储存判题任务、判题结果和日志、题目配置信息等。

Redis 与 MongoDB 服务的 CPU 占用曲线

最惨 996 加班奖,就颁给我们最惨的 RabbitMQ 同学吧!从头到尾忙不停,内存都不够用了。判题队列、判题结果处理和查重队列,都是他在负责处理,可谓是"多人运动"……咳咳……鞠躬尽瘁!下次一定给你安排上 16G 内存,别再告警了求你了 _(:з」∠)_

WeJudge RabbitMQ Service 的 CPU 占用,平均 28.65%,峰值 55.3%

接下来是判题机。之前我们拿 java 压测了一波,python 也压测了一波,也就是想看看这些高负载的评测对整个队列有啥影响。结果实际情况,确实没有压测时设想的那么恐怖。通过压力测试,也成功的怼出了判题机的一些问题,比如 WA、PE 没判对,以及测试文件太大的时候判题机出现访问文件失败的问题,这才使得我们在比赛前能够尽可能解决存在的问题。感觉下图判题机的 CPU 都没完全吃满,绰绰有余咯~(吃满你们就全 TLE 了哈哈)

判题机 Grafana 面板:判题服务器内存、每判题机每秒 CPU 占用、文件读写、k8s pod 级指标

再来看看比赛一个月来的访问量统计,PV 达到了 100W+!今日 UV 达到 3000+!

Wow! Awesome! 这是 OJ 独享的 moment…… ;-)

2020/03/27–2020/04/25 一个月趋势,浏览量 1,000,351

比赛当天 2020/04/25,浏览量 325,065,访客数 3,021

可能对于那些商业 OJ 来说,这不算什么,但是对于我们来说,这是一次前所未有的经历。感谢主办方对我们的信任,也感谢北京师范大学珠海分校信息技术学院的领导、老师对我们整个系统的人力、物力、财力上的大力支持,感谢来自五湖四海的参赛者同学们对我们的理解和支持!

最后,来感谢一下为 WeJudge 作出贡献的大家!

从 2015 年立项以来,WeJudge 前前后后更新了三个大版本。当初做这个是为了给同学们提供一个教学用的评测平台,所以,在肖红玉老师(咱们团队的指导老师)的帮助下,从 2015 年 9 月就开始使用到她的 C 语言课程中,逐步推广到整个学院在使用,也因此积累下来很多质量较高的题目,因此,也很感谢肖老师和信院的各位老师、我的同学 Wolf Zheng(@草原狼)、@QuanQqqqq 和 Tosh Qiu 等大佬,以及北师珠 ACM 协会各届的大佬,为 OJ 提供了许多优秀的题目资源和测试数据。

然后是咱们团队在初期我单枪匹马独干了 2 年多的时间里,系统存在一些自身的不足和偏见,3.0 版本以前的 WeJudge 在现在看来是一个大作业水平的作品。在经历了一个很棒的科技公司实习后(很感谢那位老板给我的实习机会),让我清楚的意识到,如果我想把它做好,就需要重头开始。在即将毕业的那一年,我很幸运遇到了两位大佬 121 和 ztr(@三好少年R某),在我们共同的努力下,把 3.0 系统做出来了。我负责架构多一些,业务代码大多数是他们在整,大家都是在同一个起跑线上成长,也见证了整个系统从 0 到 1 的过程。很感谢你们两年多来为 WeJudge 的付出!无论 WeJudge 的未来如何,我相信它带给你们的都是技术上成长和收获!

再然后,是关于这次比赛的。比赛筹备大概是 3 月份开始的,一开始接到的是说比赛我们来搞,报名也我们来搞,不仅要支付,还要小程序(??)。于是乎我们在两个星期左右的时间里,内把支付接好了,并把小程序搞了出来。期间感谢 ztr 大佬搭建微信小程序的项目(我一窍不通哈哈哈),以及我们可爱的 xj 小姐姐在开发上的帮助~考虑到比赛需要消耗较大的服务器资源,申请到的备用服务器需要做相应的配置才有用。由于疫情期间,学校没开学,我本人也毕业两年了不在学校,所以只好请实验室管理员郑义老师帮忙新服务器的安装操作系统工作,以及原有主机的内存扩容、故障硬盘更换等。郑老师辛苦啦,周末都还在帮我们装系统啥的,我有点儿过意不去,总之非常感谢啦!

最后最后,当然要感谢我们的大老板小红鱼老师了!肖老师从 15 年立项到现在一直在支持这个项目,幕后的运营、推广都是她在负责搞。可以说,如果没有她帮忙,OJ 也许就真是一个大作业玩具了,基本上是没人会用的。这次比赛的顺利进行,相信是对她辛劳和努力的一个最好的回礼!

老板的鸡腿已加,请查收:

比赛交流群里「北师珠可以给 OJ 开发小组加鸡腿哈哈」

抢到 45.76 元红包

没错,我又是那个手气最差!

大家见证了 WeJudge 的成长,WeJudge 也见证了你们的成就和荣耀!

衷心感谢大家,我们明年再见!哦不,别急,这才网络资格赛呢,还有现场赛呢!到时会有更好玩的功能出现在现场哦,也许还会在 B 站有直播?

不骄不躁,脚踏实地,继续前行!

除非另行声明,本文采用 CC BY-NC-ND 4.0 许可:署名 · 非商业 · 禁止演绎。