队列里有空闲计算资源，任务却迟迟无法启动，常见原因不是“优先级不够”，而是请求条件、资源边界或调度规则互相冲突。设计训练任务排队与资源调度机制时，新手容易只关注先来后到，却漏掉资源如何计量、何时释放，以及任务失败后怎样重新进入队列。
先说清楚“申请资源”是什么意思
任务提交时填报的资源量，必须对应调度器实际检查的指标。除了处理器核心数和内存，还可能包括本地临时盘、网络带宽、许可证名额或专用设备。若调度器只看内存和核心数，多个任务仍可能同时争用磁盘吞吐，导致运行变慢，却看不出队列已过载。
还要区分申请值、上限和实际使用量。申请值通常用于判断能否启动；上限用于限制任务使用；实际使用则来自运行监控。以 Linux cgroups v2 为例，可对进程组设置 CPU、内存等控制，但它本身不替代队列中的排队、公平分配和准入规则。配置时应把“能否启动”和“启动后最多使用多少”分开写清。
配额、借用与碎片化要一起检查
资源配额用于约束某个队列、项目或用户可占用的资源，但配额不等于资源预留：某队列达到上限时，即使其他队列暂时空闲，也可能无法继续提交或启动任务。允许借用能提高利用率，却要说明资源被原归属方需要时如何回收。
另一个容易忽略的问题是碎片化。总量看似足够，不代表有一块连续可满足单个任务的资源组合。例如，多台主机各剩少量内存，仍无法启动一个要求集中资源的大任务。对必须同时获得多项资源才能运行的任务，可评估 gang scheduling（成组调度）；它能避免部分成员长期占位等待，但可能让资源在凑齐条件前闲置。若任务能拆分，分别排队往往更灵活。
优先级不是公平策略
优先级适合表达紧急程度，却不能单独保证长期公平。低优先级任务若持续被新任务挤到后面，就会出现饥饿。可以组合使用队列权重、用户用量计账和等待时间增益：短期按重要性排序，等待时间变长后逐步提高机会。若采用抢占，应明确可被终止的任务类型、通知宽限期，以及能否从检查点恢复；不支持恢复的长任务被强行中断，可能造成较大重复计算。
用一轮小规模试运行验证规则
- 列出所有可调度资源及计量单位，标出必需项和可选项，并确认监控数据能对应到这些指标。
- 为不同队列写明容量、上限、是否允许借用，以及超过配额时是拒绝提交还是继续排队。
- 定义排序与公平规则，同时写清抢占对象、取消方式和失败后的重试间隔；避免立即重试导致故障任务反复占用资源。
- 用短任务、长任务、资源需求差异明显的任务组合做测试，检查等待时间、资源空闲、启动失败和重试次数。
- 定期根据实际使用记录调整申请模板。若任务常因申请过大而排队，可提供经过验证的规格档位；若经常触及上限，则先排查低估资源，不要只放宽全局限制。
训练任务排队与资源调度机制是否可靠，最终要看规则能否解释“为什么这个任务现在不能启动”，并能从记录中验证答案。先把资源口径、借用边界、公平方式和失败处理写成可检查的配置，再逐步放开弹性，通常比一开始追求复杂策略更稳妥。
常见问题
资源申请应该按平均用量还是峰值填写？
先结合历史运行记录确定申请值，并关注启动阶段和数据读写等可能的峰值。若任务波动明显，可用多次运行校准，避免只按平均值申请而频繁触顶。
队列配额要不要全部预留？
不一定。预留能保证特定任务有资源，但会降低空闲资源的灵活利用；允许借用利用率更高，却需定义回收条件。任务时效要求和中断代价越高，越应谨慎设置预留。
怎样判断是否发生任务饥饿？
观察同类任务的等待时间是否持续增长，并检查它们是否反复被更高优先级任务越过。若确有此情况，可增加等待时间权重或设置公平份额，而不是只继续提高优先级。
