原来的 JudgeServer 按核数起 gunicorn worker、每份提交再按核数开进程池,空闲内存跟着核数走
(2 核 52MB、16 核 305MB)。换成 go-judge 后空闲 16MB,同一批提交判题中 80–100MB(原来约 370MB)。
go-judge 只管在沙箱里跑命令,编译、逐点运行、比对输出、定状态码搬到 judge/sandbox.ts,
口径逐条照搬 JudgeServer,出参形状不变。拿生产库真实提交新旧逐点对比:C 2000 份 1989 一致、
C++ 891 份 890 一致、Python 2000 份全一致;不一致的是 system("pause")(现在不再判运行时错误)、
未定义行为、endl 死循环打印(运行时错误变运行超时),见 docker/judge/README.md。
- 判题容器改成 privileged(go-judge 要自己建 cgroup),镜像 oj2-judge-3
- 心跳改由 worker 每 5 秒问判题机 /version 代记,删掉 /api/judge-server/heartbeat
- 前端统一用 stripJudgePath 去掉判题机工作目录(新的 /w/ 和旧的 /judger/run/)
- 提交前编译检查只编译不运行
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
8.8 KiB
判题沙箱镜像
判题机跑的是 go-judge:一个 Go 写的沙箱服务,
只管「在沙箱里跑一条命令、量出用了多少时间和内存」。编译、逐个测试点运行、比对输出、
定状态码都在后端 apps/api/src/judge/sandbox.ts。
这个镜像里只有两样东西:go-judge 的单个二进制(从官方镜像 criyle/go-judge 里拷出来),
和学生程序要用的工具链。
| 版本 | |
|---|---|
| go-judge | v1.13.3(Dockerfile 的 GO_JUDGE_VERSION) |
| gcc / g++ | 14.2(trixie 默认) |
| Python | 3.13.5(trixie 默认) |
| base | debian:trixie-slim |
| 镜像体积 | 384 MB |
⚠️ 换 Python 大版本时,api 镜像(docker/Dockerfile 的 python3-minimal)要一起换。
提交前的语法检查在 api 那边用 CPython 编译一遍,前端再按报错原文翻成中文(翻译表在
apps/web/src/utils/pythonError.ts)。两边版本不一致的话,同一份代码
在提交前和判题时报的句式可能不同,翻译表只能对上其中一边。
为什么从 JudgeServer 换过来(2026-10)
之前跑的是 QingdaoU/JudgeServer(上游停更在 2024-04,我们自己重编过工具链,那是 oj2-judge-2)。
它的 gunicorn 按核数起 worker、每份提交再按核数开进程池,空闲内存跟着机器核数走:
| 空闲 | 判题中(同一批提交) | |
|---|---|---|
| JudgeServer,2 核(= 服务器) | 52 MB | — |
| JudgeServer,16 核 | 305 MB | 约 370 MB |
| go-judge | 16 MB | 80–100 MB |
判题中那一列是在 16 核的开发机上、两边同时跑同一批真实提交时量的。go-judge 同时跑几个
程序由 -parallelism 管(默认等于核数),不再随提交数翻倍。
判定和原来一样吗
后端逐条照搬了 JudgeServer 的口径(输出 rstrip 后比 md5、stdout 和 stderr 合在一起比、
地址空间限两倍内存、16MB 输出上限、墙钟是 CPU 时限的 3 倍、libjudger 的状态码顺序),
细节见 sandbox.ts 顶部。换之前拿生产库里的真实提交,同一份代码同时送进新旧两台判题机,
逐个测试点比状态码:
| 语料 | 份数 | 一模一样 | 不一样 |
|---|---|---|---|
| C 提交(共 19757,随机抽样) | 2000 | 1989 | 11 |
| C++ 提交(全量) | 891 | 890 | 1 |
| Python 提交(共 115492,随机抽样) | 2000 | 2000 | 0 |
不一样的全部是下面三种,都是有意接受的:
system("pause")(Dev-C++ 留下的习惯):原来 seccomp 直接杀,运行时错误、信号 31; 现在学生程序开不了子进程,system()返回 -1,程序照常往下跑、按输出判。全库这样判成 运行时错误的一共 63 条,2026-09 以后一条没有。- 未定义行为:读越界的数组元素(
max = num[10])、没读进值的变量。读到的垃圾值取决于 栈上原来有什么,换了沙箱就换了一批垃圾。库里存的结果本来就和旧判题机现在重跑的对不上。 - 死循环里用
endl打印(C++ 那 1 条):原来 CPU 时间只算用户态,先写满 16MB 判运行时错误; 现在内核态也算(每次endl刷新都是一次系统调用),先到 1 秒判运行超时。都是错,说法不同。
另外几处数字会变,不影响判定:
- 内存读数变小:现在是 cgroup 的峰值,原来是 ru_maxrss。C 的空程序 0.25 MB(原来 1.5 MB),Python 2–5 MB(原来 8 MB)。程序打印的输出也算在内存里(写在 tmpfs 上)。
- CPU 时间含内核态,原来只算用户态。读大输入的程序会多出几毫秒。
- Python 的回溯路径是
/w/solution.py,原来是/judger/run/<随机串>/solution.py。 前端显示前两种都会去掉(apps/web/src/utils/judge.ts的stripJudgePath)。 编译错误是相对路径(main.c:3:5、File "solution.py"),不受影响。
判题机容器为什么是 privileged
go-judge 要给每个学生程序建 namespace(看不到网络、别的进程、宿主的文件)和 cgroup(限内存、
数进程),这些在普通容器里做不了。试过不给特权:要同时加 SYS_ADMIN、关掉 Docker 的
seccomp 和 AppArmor、去掉 /proc /sys 的遮罩、再在容器里把 cgroup 重新挂成可写 ——
那几乎就是特权了,还更脆,换台宿主机就可能起不来。所以照 go-judge 官方的做法给 privileged: true。
学生程序本身是关在 go-judge 自己的沙箱里的(独立的 mount / pid / net / ipc / uts / user namespace、cgroup、seccomp),比原来 libjudger 只有 seccomp + setuid 关得更严。
宿主机要求:cgroup v2(Debian 12 起默认就是),内核 ≥ 5.19 时内存峰值用 memory.peak,
更老的内核退回 maxrss(读数偏大一点)。起不来时 docker logs oj-judge 里会有
create environment builder failed。
镜像源
默认走清华源(Dockerfile 顶部两个 ARG)。官方源在这边实测 197 KB/s,清华
3.9 MB/s。
build.sh --no-mirror 换回官方源。debian 那两个只能用 http —— 改 sources 发生在
装 ca-certificates 之前,base 镜像里没有 CA 根证书,https 一律
certificate verify failed(这个坑踩过)。
go-judge 那层是从 Docker Hub 拉 criyle/go-judge:<版本>,构建机要能拉到它。
构建与分发
docker/judge/build.sh --save # 本机构建 + 导出 dist/oj2-judge-3.tar
scp dist/oj2-judge-3.tar root@服务器:/root/OJDeploy/
ssh root@服务器 'docker load -i /root/OJDeploy/oj2-judge-3.tar'
# 机房那台同样来一遍 —— 两个站点各有各的判题沙箱
之后正常 docker/deploy.sh 即可。判题机和 api / worker 要一起换:新后端只会说
go-judge 的话,旧判题机只认旧后端。
⚠️ 这个名字不在任何 registry 上。 服务器上忘了 docker load,deploy.sh 的自检会拦下。
⚠️ 改工具链或升 go-judge 就把末尾的序号 +1(下一版叫 oj2-judge-4:build.sh 里的
IMAGE、三个 compose 里的 image,一起改)。docker compose up -d 不带 --pull,名字没变会静默
用机器上的旧镜像。
回滚:JudgeServer 那版(oj2-judge-2)只认 2026-10 之前的后端,要连代码一起回退到换判题机之前
的提交再部署。别在服务器上 docker image prune 把 oj2-judge-2 清掉。
和后端的分工
- 编译和运行命令在
apps/api/src/judge/languages.ts,不在镜像里。镜像只负责把/usr/bin/gcc、/usr/bin/g++、/usr/bin/python3这些绝对路径挂到正确的版本上 (Dockerfile 里的update-alternatives)。恢复一种语言要两边一起改,缺一个都是静默失败。 - 沙箱里能看到哪些目录在
mount.yaml:/usr、/lib这些只读,工作目录/w和/tmp各是一块 128MB 的 tmpfs。 - 测试点不经过 api:学生程序的 stdin 直接从判题机容器里的
/test_case/<id>/N.in开 (镜像的-src-prefix=/test_case,别的路径一律拒)。比对用的stripped_output_md5由 api 从同一个目录的info里读。所以 compose 里判题机和 api 挂的必须是同一个测试点目录。 - 程序输出不内联回传:每个测试点的输出(最多 16MB)留在判题机的文件存储里,api 用
GET /file/:id按原始字节取回来比 md5,然后删掉。直接塞在 JSON 里的话,死循环打印的 16MB 会在 worker 里膨胀成几倍。api 半路崩了没删的,判题机 10 分钟后自己清(-file-timeout)。 - 心跳:go-judge 不主动报,worker 每 5 秒问一次
/version,替它在judge_server表里记一笔 (apps/api/src/judge/heartbeat.ts)。后台列表里两台分别叫「服务器」「机房」(compose 的JUDGE_SERVER_NAME)。 - 鉴权:
Authorization: Bearer <OJ2_JUDGE_TOKEN>,go-judge 从ES_AUTH_TOKEN读。原来 JudgeServer 收的是 token 的 sha256,现在是原文。
gcc-14 把隐式函数声明、int↔指针互赋、不兼容指针类型从 warning 提成了 error,-w
压不住。languages.ts 里的 cLooseErrors 里的 -Wno-error= 就是为此加的 ——
2026-09 升 gcc-14 时实测 1951 份历史 C 提交和 20 篇 C 教程的 93 个代码块,加了之后与
gcc-13 逐个文件结果完全一致;不加的话有 26 份会从「能过」变成 CE(按比例算全库约 260 条),
全是忘了 #include <string.h> 之类的隐式函数声明。
换镜像后怎么验
bun docker/judge/smoke.ts # 三种语言 + 六种状态码 + gcc 宽松度 + 几条照搬的口径
它走的就是线上那份 sandbox.ts,不需要起后端、不需要库里有题,测试点内联传。
判题机装好之后,后台「判题机列表」应该能看到它上线(worker 起来 5 秒内)。