前言：把前面所有内容串成一套体系

这是「LSF 集群配置系列」的第三篇，也是完结篇。前面两篇分别讲了 lsf.cluster.cluster_name 的基础结构与集群管理员权限，以及 lsf.shared 自定义资源与 ResourceMap 的阈值控制；再往前的系列文章还讲过 lsb.queues、lsb.hosts、lsb.users、lsb.params、lsb.applications、lsb.resources、lsb.modules 七个批处理层配置文件。单独看每一篇，都是在讲某一个文件“能做什么”；这篇要解决的问题是：面对一个几十人、多项目组共用的真实 CAD Farm，这些配置该怎么组合起来，形成一套“谁能用、能用多少、超了怎么办”的完整体系。

***本系列以 IBM Spectrum LSF 10.1 为基准。LSF 各个 Fix Pack 之间个别参数的行为/语义存在过调整（比如排队相关的限额参数），文中给出的是主线行为，具体细节请以你实际安装版本对应的官方文档为准，不要机械照搬。

本篇要回答的四个核心问题

• 如何限制用户使用——某个用户/项目组能不能提交作业到这个队列？能同时跑多少个？

• 如何限制资源使用——某个用户/项目组的作业总共能占用多少 CPU、内存、license？

• 如何配置最小/最大资源使用量——防止申请过少导致资源预留失效、或申请过多导致资源浪费和挤占。

• 如何配置各种阈值——从主机负载阈值到作业并发阈值，多层阈值该如何搭配，才不会互相冲突或留下漏洞。

一、多级权限模型：谁能管什么

回顾一下系列第一篇里提到的权限分层——集群管理员、队列管理员、用户组管理员，这里把它扩展成一张完整的责任矩阵，并补充「谁能限制谁」这个维度。

1.1 完整权限矩阵

✅ 最佳实践：给每一层角色发放权限前，先问一句“这个人真的需要更高一级的权限吗，还是只是想解决”自己作业管理不方便“这个具体问题”——大多数“能不能给我加个队列管理员权限”的请求，本质需求其实是“我想在自己的作业卡住时能自己处理”，用户组管理员的权限往往已经够用，不必层层上调到队列管理员甚至集群管理员。

1.2 常见反模式：权限扁平化

⚠️ 注意：很多 CAD Farm 在早期规模小的时候，图省事把所有骨干工程师都加进 ClusterAdmins，随着团队扩张，这个列表会越滚越大，变成“谁都能改配置、谁都能杀别人的作业”的失控状态，一旦出现误操作（比如手滑 badmin qclose 关掉了别人在用的队列），很难在多个“管理员”之间定位是谁做的。建议无论集群规模大小，都坚持“集群管理员只保留 1~2 名核心运维、其余人走队列/组管理员”的收敛设计。

二、用户资源限额矩阵设计方法

限额配置最容易踩的坑不是“不知道怎么写参数”，而是“没有提前想清楚要限制的到底是什么维度”。这一节给出一个可以直接套用的设计流程。

2.1 三个维度：并发（Job Slot / Job 数）、资源量、时间

⚠️ 注意：这里特意把“并发数”拆成两行，是因为 EDA Farm 里这是一个非常容易踩的坑：MAX_JOBS/UJOB_LIMIT/QJOB_LIMIT/MXJ 这些参数名字虽然带“JOB”，但 IBM 官方对它们的定义都是 job slot 数量，不是作业数量。对于串行作业（1 个作业=1 个 slot）两者没区别；但只要涉及 bsub -n 提交的并行仿真作业，“最多用 40 个 slot”和“最多同时跑 40 个作业”就是完全不同的两件事——如果真正想限制的是“作业数量”，要用 lsb.resources 的 JOBS 参数，本篇第三章 3.7 节会结合实际案例展开讲这个区别。

设计限额时建议按这几个维度依次过一遍，而不是想到哪个配哪个。比如给“回归仿真”这类作业设计限额，完整的思路应该是：并发上，这个项目组同时最多占用多少 job slot（避免占满整个仿真农场），如果业务上更关心“作业数量”而不是核数，还要额外考虑 JOBS 参数；资源量上，license 和内存的总占用上限是多少；时间上，单个回归任务超过多久算异常（该被系统自动杀掉而不是无限占着资源）。这几者缺一不可，只配置了 job slot 限制、没配置资源量限制的情况在实践中很常见，也是最容易出问题的疏漏。

2.2 从组织架构反推限额矩阵

实际操作中，建议先画一张“项目组 × 资源类型”的矩阵表，把每个项目组在每类资源上应该拿到的份额定下来，再翻译成配置文件。下面是一个三个项目组共享一个 CAD Farm 的示例矩阵——注意这里的上限列写的是“Job Slot 上限”而不是笼统的“并发作业上限”，呼应前面强调的 Job 和 Job Slot 的区别；如果业务上还需要单独控制“活动作业数量”，可以再加一列 Active Job 上限，用 lsb.resources 的 JOBS 参数落地，本例暂不展开：

***这张表本身不是配置文件，而是配置前的规划产物——建议作为团队内部文档长期维护，每次调整配置前先改这张表、评审后再落地到配置文件，能大幅减少“改了才发现影响了别的组”的返工。

三、实战：把矩阵落地为完整配置

接着上一节的矩阵示例，这一节给出对应的完整配置片段，横跨 lsf.cluster、lsf.shared、lsb.users、lsb.queues、lsb.resources 五个文件，展示它们是如何配合工作的。

3.1 第一步：lsf.cluster.cluster_name 定义集群管理员与主机分组标签

***这里 Host 段 RESOURCES 列打的 dig_pool/ana_pool/verif_pool 是静态 Boolean 资源标签，用途是配合 bsub -R 或队列的 RES_REQ 里的 select[] 语句筛选主机（回顾系列第一篇 2.5 节）。它和接下来 ResourceMap 段的 LOCATION、以及 lsb.queues 的 HOSTS 参数是两套不同的语法体系，都不能直接拿资源标签名当主机名或主机组名来用——下面两步分别会踩到这个边界，要格外注意。

3.2 第二步：lsb.hosts 定义 HostGroup，把主机按项目组分组

在圈定队列可用主机池（lsb.queues 的 HOSTS 参数）之前，需要先在 lsb.hosts 里用 HostGroup 段给主机分组——HOSTS 参数只接受显式主机名、HostGroup 名或 all 关键字，不能直接填 Host 段 RESOURCES 列里的资源标签名，两者是完全不同的语法层面。

3.3 第三步：lsf.shared + ResourceMap 定义并拆分 license

⚠️ 注意：这里必须用显式主机名列表 [digfarm01 digfarm02]，不能写成 [dig_pool]——ResourceMap 段的 LOCATION 语法只接受显式主机名、all/others/default 关键字，不认 Host 段 RESOURCES 列里的资源标签，也不认 lsb.hosts 的 HostGroup 名。这是系列第二篇 3.2 节已经强调过的规则，这里再次提醒，因为拿资源标签当主机列表用是最容易犯的错误之一，写错了 reconfig 不一定报错，但资源不会按预期分配。

***这里再澄清一个容易理解错的地方：15@[digfarm01 digfarm02] 表示 digfarm01 和 digfarm02 这两台主机共同共享一份数量为 15 的 calibre_dv license，不是“每台主机各自拥有 15 个”（那样两台加起来就变成 30 个了）。IBM 官方 ResourceMap 的语义就是“方括号内的这组主机共享同一份数量”，如果确实希望每台主机各自独立拥有一份资源，需要分别给每台主机单独映射一条（比如 console (1@[cadmgr01] 1@[cadmgr02]) 这种写法，每台各自 1 个、互不共享）。

3.4 第四步：lsb.users 定义用户组与并发限额

⚠️ 注意：这里组名故意不加 @，是要精确匹配第二章矩阵里“数字设计组总共最多 40”这个设计目标——组名不加 @ 表示这个 MAX_JOBS 上限是整个组共享的总量（Alice+Bob+Carol 加起来 ≤ 40），加了 @（写成 dig_design@）则表示组内每个成员各自独立拥有 40 的上限（Alice 自己就能用到 40、Bob 也能用到 40，互不影响）。这两种语义差异巨大，务必对照自己的业务需求选择，写错了不会报错、但实际生效的配额和预期完全不同。另外还要注意：MAX_JOBS 这个参数名字虽然叫“Job”，但 IBM 官方对它的定义其实是 job slot 总量，不是作业数量——3.7 节会专门展开这个区别。

***USER_SHARES 列里的 ([each,1]) 定义的是这个用户组在公平共享份额树（share tree）里的层级配置——组内每个成员各自均分 1 份。它本身只是“定义份额”，真正让这份配置在某个队列里生效、按份额而非先到先得分配运行机会的，是队列里的 FAIRSHARE 参数（比如下面 verif_farm 队列的 FAIRSHARE = USER_SHARES[[each,1]]）——两者是配合关系：lsb.users 定义“树”，lsb.queues 的 FAIRSHARE 决定“这个队列要不要用这棵树来调度”，同一份 USER_SHARES 配置可以被多个队列各自引用。

3.5 第五步：lsb.queues 圈定主机池 + 资源需求 + 最小/最大限制

⚠️ 注意：同理，HOSTS 参数这里必须填 3.2 节定义好的 HostGroup 名字（dig_group/ana_group/verif_group），不能直接填资源标签名 dig_pool——如果写成 HOSTS = dig_pool，LSF 会把 dig_pool 当成一个主机名去找，显然找不到这台机器，配置不会按预期生效。如果确实想通过资源标签来筛选主机（而不是硬性圈定候选池），正确做法是在 RES_REQ 里用 select[dig_pool]，比如 ana_sta 队列里的 select[bigmem] 就是这种用法——HOSTS 和 select[] 语义不同：HOSTS 是硬性圈定队列的候选主机范围，select[] 是在候选范围内按条件筛选，两者不能互相替代，需要根据业务意图选择合适的方式。

***再澄清一个容易产生误解的地方：dig_regress 队列里的 RES_REQ = rusage[calibre_dv=1] 表示的是“每个作业预留/消耗 1 个 calibre_dv”，这是单个作业的资源需求，不代表整个队列只能同时跑 1 个作业。这个队列实际能同时调度多少个作业，取决于 3.3 节 ResourceMap 里分配给数字组的 15 个 license 总量、加上 3.4 节的 job slot 限制、加上主机本身的 CPU/内存等其他资源约束共同决定——多个约束条件同时满足才能派发，任何一个卡住都会导致作业排队。

3.6 第六步：lsb.resources 补充用户组维度的资源配额

前面 ResourceMap 已经把 license 资源池隔离到了两个主机池，但如果还想对“用户组”这个维度再加一层总量控制（比如即使 license 够用，也不希望某个组一次性把内存资源全占满），lsb.resources 提供了跨用户、队列、主机、项目、应用等多个消费者维度的资源分配限制能力，可以和前面已有的 job slot 限制组合使用：

⚠️ 注意：这里有一个语法上很容易写错的地方：PER_HOST 不是 Y/N 开关参数，而是要填主机列表、HostGroup 名或 all 关键字（比如 PER_HOST = all 或 PER_HOST = digfarm01 digfarm02），表示“这条限制分别应用在每一台指定主机上”。另外 IBM 官方规定：MEM/SWP/TMP 用百分比表示时，必须指定 PER_HOST 并列出主机范围，不能用 HOSTS 参数——这也是为什么这里用 PER_HOST 而不是 USERS+HOSTS 的组合。

***这里的 MEM = 70% 配合 PER_HOST = all，表示的是“dig_design 组的作业，在集群里的每一台主机上，各自不能超过该主机物理内存的 70%”，是相对于单台主机内存的百分比，而不是相对于集群总内存的百分比——比如 256GB 内存的主机上限是 179.2GB，512GB 内存的主机上限是 358.4GB，各台主机独立计算，不汇总成一个集群级总量。

⚠️ 注意：这里的 MEM 是 lsb.resources 的 Resource Allocation Limit，本质是调度层面的资源分配配额统计，不等价于 Linux cgroup 那种“超过就强制杀进程”的硬内存限制。如果目标是让作业实际运行时的内存消耗被操作系统层面强制限制住（超限直接 kill），需要另外配置系列第二篇提到的 MEMLIMIT/LSB_JOB_MEMLIMIT，或者更彻底的 cgroup 内存强制机制，两者是不同层面的手段，不要以为配了这里的 MEM=70% 就等于有了硬性的进程级内存保护。

3.7 一个容易被忽略的区分：Job 数量 vs Job Slot 数量

前面 3.4 节 lsb.users 里配置的 MAX_JOBS，名字虽然叫“Job”，但 IBM 官方对它的定义其实是“Total number of job slots”——也就是说 MAX_JOBS 限制的是这个用户/组总共能占用多少个 job slot，而不是能同时跑多少个作业。对于普通串行作业（一个作业占 1 个 slot），两者数值上没有区别；但 EDA Farm 里大量使用 bsub -n 提交的并行仿真作业，一个作业可能占用几十个 slot，这时候“MAX_JOBS=40”和“最多跑 40 个作业”就完全是两回事了——如果 3 个作业各自申请 16、16、8 个 slot，加起来已经用满 40 个 slot 触顶限制，即使当前只有 3 个作业在跑。

⚠️ 注意：lsb.users 的 MAX_JOBS、lsb.queues 的 UJOB_LIMIT/QJOB_LIMIT/HJOB_LIMIT、lsb.hosts 的 MXJ/JL_U，这些参数管的都是 job slot 数量；而 lsb.resources 的 JOBS 管的是“运行中和挂起中（RUN/SSUSP/USUSP）的作业数量”，两者语义不同、不能混用。如果业务需求是“这个组最多允许 40 个作业同时处于运行/挂起等活动状态，不关心每个作业占多少 slot”，应该用 JOBS；如果需求是“这个组最多同时占用 40 个 CPU slot”，应该用 MAX_JOBS（或 lsb.resources 的 SLOTS）。混淆这两者，在只跑串行作业的环境里不会有问题，但一旦引入并行仿真作业就会导致实际效果和预期完全不同。

3.8 验证整套配置

✅ 最佳实践：六个文件改完不要一次性全部 reconfig，建议按“lsf.cluster/lsf.shared → lsb.hosts → lsb.users → lsb.queues → lsb.resources”的顺序逐层验证，每改一层就跑一遍对应的查看命令核实，出问题能快速定位是哪一层的配置有误，而不是面对一堆报错无从下手。

⚠️ 注意：这里再强调一次系列第二篇提到过的边界：bhosts -s 看到的是 LSF 自己记账的 Shared Resource 状态，反映的是“通过 LSF 提交的作业消耗了多少”，不能替代对 license server（如 FlexLM）的真实 checkout 查询。如果有人绕开 LSF 直接启动 EDA 工具占用了 license，这里看到的数字和 license server 的真实剩余量会不一致，本篇用的是静态记账方案，这个局限性需要提前和团队讲清楚。

四、多层阈值如何搭配才不冲突

配置到这一步，同一个作业在提交时可能同时受到好几层限额约束：用户级 MAX_JOBS、队列级 UJOB_LIMIT、主机级 MXJ、资源级 RESRSV_LIMIT、Limit 段的总量限制……这些限制到底是什么关系？谁优先谁生效？这一节把关系理清楚。

4.1 同类限制取更严格值，不同维度的限制分别独立生效

准确的说法是：多层限制不是简单粗暴地把所有数值取一个 min()，而是几个不同维度的限制同时生效、互不替代。对于存在明确叠加关系的同类限制，LSF 会按对应参数的规则取有效约束——举例来说，MAX_JOBS 和 UJOB_LIMIT 都是 job slot 维度的限制，如果用户级 MAX_JOBS=40、队列级 UJOB_LIMIT=20，该用户在这个队列里实际能用的 slot 数是 20（更严格的那个）；JOBS 和 SLOTS 同时配置时同理，取更严格的限制生效。但像 RUNLIMIT=10小时、RESRSV_LIMIT 里的 mem 上限、MAX_JOBS、FAIRSHARE 份额这几个参数，分别管的是运行时长、资源预留范围、slot 数量、调度优先级四个完全不同的维度，它们不是“取其中最小值”的关系，而是四套约束/调度机制同时独立作用于同一个作业。

4.2 按限制的性质分类，而不是按“谁松谁紧”排序

与其把这些限制想象成一个从上到下、从松到紧的固定层级（这种理解容易让人误以为存在一种严格的先后顺序，但实际上很多限制是可以任意组合、共同生效的，并没有谁天然“管辖”谁），不如按它们限制的性质分类理解，会更接近 LSF 实际的行为：

***排查“为什么我的作业迟迟不跑”这类问题时，不要预设某一类限制天生比另一类“优先级更高”，而是要按上表这几个类别分别排查：先看物理主机 MXJ 是否已经打满、再看 lsb.resources 的资源配额是否还有余量、再看队列/用户的 job slot 限制是否触顶、最后看有没有 RESRSV_LIMIT 之类的申请范围问题——这几类互相独立，任何一类卡住都会导致作业排队，不存在“上层通过了下层就一定通过”这种从属关系。

4.3 常见冲突场景与解决方式

• 场景一：用户级 MAX_JOBS 设置得比队列级 UJOB_LIMIT 还小——两者都是 job slot 维度的限制，用户实际能用的 slot 数以更小的那个为准，通常是配置疏忽，检查两者数值是否符合预期意图。

• 场景二：RESRSV_LIMIT 的上限比 ResourceMap 分配给这个主机池的资源总量还大——RESRSV_LIMIT 限制的是单个作业的申请范围，不代表能保证申请到，如果池子总量不够，作业依然会排队等待，这不是配置错误，是正常的资源紧张现象。

• 场景三：FAIRSHARE 和 RESRSV_LIMIT 同时配置——公平共享决定的是“谁先拿到运行机会”，RESRSV_LIMIT 决定的是“每次能拿多少”，两者维度不同、互不冲突，可以放心同时使用。

• 场景四：MAX_JOBS 已经设置得很宽松，但作业还是大批量排队——如果作业是并行提交（bsub -n），先检查是不是 job slot 总量被少数几个大作业占满了，而不是同时运行的作业数太多，这正是 3.7 节讲的 Job 数量和 Job Slot 数量混淆导致的典型排查误区。

五、标准操作流程：新用户 / 新项目组开通

有了前面的体系设计，日常最高频的运维操作——给新入职工程师开通权限、给新项目组分配资源——就可以变成一套可复制的标准流程，而不是每次都临时现想怎么配。

5.1 新用户加入已有项目组

✅ 最佳实践：把限额配置在“组”这一级，新人入职只需要一步——加入对应的用户组——就能自动获得这个项目组已经设计好的完整限额，不需要每次给个人重新配置一遍，这是前面强调“从组织架构反推限额矩阵”的直接收益。

5.2 新项目组从零开始

• 第一步：和项目负责人一起，按第二章的方法画出资源限额矩阵（并发数/license/内存/时间）。

• 第二步：如果需要专属主机池，在 lsf.cluster.cluster_name 的 Host 段给主机打上新的 RESOURCES 标签（用于 select[] 筛选），同时在 lsb.hosts 里新建对应的 HostGroup（用于队列的 HOSTS 参数），两者不能混用，具体区别参见本篇 3.1~3.2 节。

• 第三步：如果涉及独立的 license 配额，在 lsf.shared 定义资源（如果是新资源类型）+ ResourceMap 用显式主机名拆分数量。

• 第四步：在 lsb.users 新建 UserGroup，把矩阵里的 Job Slot 上限落地为 MAX_JOBS，排队上限落地为 MAX_PEND_JOBS（注意 MAX_PEND_JOBS 及相关排队限制参数在不同 LSF 版本/Fix Pack 之间存在语义演进，落地前建议核对自己集群实际安装的版本文档）。

• 第五步：在 lsb.queues 新建专属队列，HOSTS 参数填第二步建好的 HostGroup 名，把矩阵里的资源量落地为 RES_REQ/RESRSV_LIMIT/RUNLIMIT。

• 第六步：badmin ckconfig -v 检查语法，按顺序 reconfig，逐项验证。

• 第七步：给项目负责人开通 GROUP_ADMIN 或队列 ADMINISTRATORS 权限（视团队规模决定给哪一级）。

六、系列总结

到这里，「LSF 集群配置系列」的核心内容就完整了。回顾一下整条主线：

• lsb.queues / lsb.hosts / lsb.users：作业调度策略、主机负载阈值、用户并发限额——「批处理层」的三大核心文件。

• lsb.params / lsb.applications / lsb.resources / lsb.modules：集群级全局参数、应用画像、跨队列资源配额、调度器插件开关——「批处理层」的四个补充文件。

• lsf.cluster.cluster_name：集群定义、主机清单、集群管理员权限——「集群层」的基础配置。

• lsf.shared 的 Resource 段 + lsf.cluster.* 中的 ResourceMap 段：自定义资源的定义与精确映射——把 license、GPU 这些稀缺资源管理精细化的关键（这里明确一下：ResourceMap 不是独立的配置文件，而是 lsf.cluster.cluster_name 文件里的一个配置段，和 Host 段、ClusterAdmins 段同属一个文件，回顾系列第一篇）。