SGE批量任务停滞求助:队列因过载或已满被丢弃
嘿,从你给出的qstat输出、任务详情和配置来看,核心问题就是所有SGE队列被标记为"full",导致新任务根本没法调度。结合你的Docker Swarm + NFS共享存储的环境,我整理了几个优先级从高到低的调整方案,你可以一步步试:
一、先清掉占着槽位的“僵尸”任务/进程
从单个任务的资源占用来看(cpu=00:00:02, mem=0.59503 GBs),任务本身应该很快就能跑完,但队列的20个槽位被占满后就没释放,大概率是任务跑完后没正确退出,或者SGE没检测到任务结束。
先找僵尸进程
登录到每个客户端节点(sge00到sge03),执行这条命令看看有没有僵死的进程:ps aux | grep defunct如果发现一堆,那就是你的
lineage.py脚本有问题——比如子进程没回收、资源没释放,得先优化脚本,确保所有子进程都能正常终止,或者在脚本末尾加个清理逻辑。强制清理停滞任务
对于已经卡死的任务,直接批量清掉就行:qdel -u root # 清理root用户的所有任务,要是你用别的用户跑就改一下或者指定任务ID范围清理,比如:
qdel 1595799-1600000
二、调整SGE调度器配置,别让它误判负载
你的调度配置里,load_formula设成了np_load_avg=100.0,这很容易让调度器误以为节点过载;另外maxujobs=0意味着不限制用户的并行任务数,很容易把队列直接塞满。
- 修改调度器配置
找到SGE的调度配置文件(一般在$SGE_ROOT/$SGE_CELL/common/sched_conf),调整这几个参数:
改完后加载新配置并重启调度服务:# 改负载计算公式,结合CPU和剩余内存判断,别光看CPU load_formula np_load_avg=0.75,mem_free=0.25 # 限制每个用户的最大并行任务数,你4个节点每个20槽共80,设成60-70比较稳妥 maxujobs 70 # 缩短负载衰减时间,让调度器更快感知节点负载变化 load_adjustment_decay_time 0:2:00qconf -Msconf sched_conf service sge_scheduler restart
三、优化队列配置,给任务加“保险”
当前队列是固定20个槽位,还没设负载阈值,结合Docker环境,我们给队列加些弹性和容错机制:
- 修改队列配置
用qconf -mq peteris.q编辑队列配置,调整这些参数:
另外,因为你用Docker部署,如果SGE支持Docker集成的话,还可以在# 设置CPU负载阈值,节点CPU负载超过80%就不再分配任务 load_thresholds np_load_avg=80.0 # 开启任务自动重跑,单个任务卡住也不会一直占着槽位 rerun TRUE # 设置任务最大运行时间,防止任务无限期卡着(根据你的任务实际时长改,比如设10分钟) h_rt 00:10:00 # 限制虚拟内存,避免单个任务吃太多内存把节点搞卡 h_vmem 2Gcomplex_values里加Docker相关配置,确保任务在容器里正确隔离。
四、优化NFS存储,别让IO拖后腿
NFS共享是批量任务的常见坑,任务读写大量文件时很容易IO阻塞,看起来就像任务停滞了:
检查NFS挂载参数
每个客户端节点都看看NFS挂载选项,确保加了async、noatime这些优化参数:mount | grep nfs要是没加,就改
/etc/fstab里的挂载行,比如:nfs-server:/data /data nfs defaults,async,noatime,rsize=8192,wsize=8192 0 0然后重新挂载:
mount -o remount /data分散文件存储压力
把任务的输入输出文件分散到多个NFS目录,或者先用本地临时目录(比如容器里的/tmp)处理中间文件,跑完再同步回NFS,这样能大大减少NFS的IO压力。
五、加个监控,提前发现问题
为了避免再踩坑,建议加些监控:
- 定期用
qstat -f看队列状态,或者写个小脚本监控槽位使用率,超过90%就报警; - 用
iostat、nfsstat监控NFS服务器的IO负载,及时发现存储瓶颈; - 用
docker stats监控容器的资源使用,确保容器有足够的CPU和内存。
内容的提问来源于stack exchange,提问作者kim jason

