在对python批量判题的时候，大概1小时后，iowait急剧升高到最后机器就挂了

[bilibvivo]

描述问题 io占用异常

如何复现 jmeter 或 java 压入20 万Python题目（随机参数、判题结束状态） 等待判题结果

服务器配置 服务器八核16g，CentOS Linux release 7.8.2003

问题记录

• io占用异常（重启服务器后正常） 20w Python，judge_client 配置为8，此配置下判题运行1h20min 后 iowait开始持续升高，io占用的进程为内核进程[kworker/u16:0] 和 拷贝Python依赖 cp -a /usr/lib64/python3.6 /home/judge/run7//usr/lib64/ 命令

运行4h后判题速度下降为0.68题/s，此时约判题2.8w题。

[MX-Qulin]

(服务器不错,豪👍)

CentOS系统不太清楚cp命令是不是并发大了会卡住,可能是系统层面的问题...

另外,不清楚您的测试方法(本地命令调用judge?) 如果WEB压入20W可能数据库直接炸了...

(OJ不是用来卡的,20W太大.普通OJ 1W份代码积压就炸了)

如果想要提高性能,可以在judge.conf内设置OJ_TURBO_MODE=1

(设置OJ_RUNNING=4可能可以解决这个问题)

[renbaoshuo]

我觉得并发还是太大，这程度基本没OJ能抗的下来吧...

IO问题可以上SSD？

[bilibvivo]

(服务器不错,豪👍)

CentOS系统不太清楚cp命令是不是并发大了会卡住,可能是系统层面的问题...

另外,不清楚您的测试方法(本地命令调用judge?) 如果WEB压入20W可能数据库直接炸了...

(OJ不是用来卡的,20W太大.普通OJ 1W份代码积压就炸了)

如果想要提高性能,可以在judge.conf内设置OJ_TURBO_MODE=1

(设置OJ_RUNNING=4可能可以解决这个问题)

我们数据库规格也是8C16G，判题数据通过脚本直接插入数据表，20w条对数据库来说肯定不是问题，我们就是直接启动judged服务，8个并发处理进程配置。等20w条数据全部插完后，统一sql设置判题状态为0，然后judged服务就会从数据表里拉数据了。

[bilibvivo]

我觉得并发还是太大，这程度基本没OJ能抗的下来吧...

~IO问题可以上SSD？~

8核服务器开8个judged进程并发算小把，这应该可以提高到cpu核数的2-3倍才算最大利用cpu核数。

[MX-Qulin]

我觉得并发还是太大，这程度基本没OJ能抗的下来吧... ~IO问题可以上SSD？~

8核服务器开8个judged进程并发算小把，这应该可以提高到cpu核数的2-3倍才算最大利用cpu核数。

没错,但是现在的情况说明瓶颈在IO上,所以建议缩小OJ_RUNNING,看看IO能不能扛得住.

iowait升高原因(猜测,无法复现):python环境cp命令读写次数过高,日志写入过多

解决方案:换c++作为提交语言 或者 使用沙箱评测...

(不清楚压20W份代码的意义...)(逃ε=ε=ε=┏(゜ロ゜;)┛

[zhblue]

try add settings in judge.conf

OJ_PYTHON_FREE=1

massive python tasks will work better with a few security loss

[bilibvivo]

try add settings in judge.conf

OJ_PYTHON_FREE=1

massive python tasks will work better with a few security loss

I try see see..