直接调高文件描述符限制（ulimit -n）并同步加固内核级资源配额，是解决jenkins master因多项目并发构建耗尽fd导致假死或卡顿的核心手段；需协同放开用户级、服务级、内核级三层限制，并通过ulimit -n、ls /proc/.../fd | wc -l和cat /proc/sys/fs/file-nr验证瓶颈。
直接调高文件描述符限制（ulimit -n）并同步加固内核级资源配额，是解决 Jenkins Master 因多项目并发构建耗尽 fd 导致假死或卡顿的核心手段。关键不是单点调参，而是用户级、服务级、内核级三层限制必须协同放开。
确认当前瓶颈是否为文件描述符耗尽
运行以下命令快速验证：
-
ulimit -n—— 查看当前用户允许打开的最大文件数（默认常为 1024） -
ls /proc/$(pgrep -f 'jenkins.*jar')/fd | wc -l—— 查看 Jenkins 主进程实际打开的 fd 数量 -
cat /proc/sys/fs/file-nr—— 查看系统已分配/已使用/总上限的文件句柄数（第三列即file-max） - 若 Jenkins 日志中频繁出现
Too many open files、java.io.IOException: EMFILE或构建任务卡在 Workspace 初始化阶段，基本可判定为 fd 耗尽
永久提升 Jenkins 用户级文件描述符上限
编辑 /etc/security/limits.conf，为 Jenkins 运行用户（如 jenkins）添加明确配置（不要用 *，避免被其他服务干扰）：
jenkins soft nofile 65535<br>jenkins hard nofile 65535<br>jenkins soft nproc 65535<br>jenkins hard nproc 65535
确保 PAM 加载生效：检查 /etc/pam.d/common-session 是否含 session required pam_limits.so；若使用独立用户登录启动 Jenkins（如 via su - jenkins -c "java -jar..."），需重新登录或重启会话才生效。
适配 systemd 服务托管场景（Debian/CentOS 常见）
系统包安装的 Jenkins（如 apt install jenkins）由 systemd 托管，limits.conf 对其无效。必须显式声明服务资源限制：
- 编辑
/etc/systemd/system/jenkins.service.d/override.conf（如不存在则新建目录和文件） - 写入：
[Service]<br>LimitNOFILE=65535<br>LimitNPROC=65535
执行 sudo systemctl daemon-reload && sudo systemctl restart jenkins 生效。可通过 systemctl show jenkins | grep LimitNOFILE 验证。
兜底：调高内核全局文件句柄上限
即使用户级设为 65535，若 /proc/sys/fs/file-max 过低（如默认 74377），高并发构建仍可能触发内核级拒绝。建议按物理内存比例设置：
- 临时生效：
sudo sysctl -w fs.file-max=2097152 - 永久生效：在
/etc/sysctl.conf中追加fs.file-max = 2097152，再执行sudo sysctl -p - 该值应 ≥ 所有 Jenkins Agent + Master 的
LimitNOFILE × 并发任务数总和，并预留 20% 余量
不复杂但容易忽略：Jenkins Master 上每个构建任务、每个 Pipeline Stage、每个 Shell 步骤 spawn 的子进程、每个 HTTP 连接（如 Artifactory 插件）、每个日志轮转句柄都在消耗 fd。只改 ulimit 不碰 systemd 和 file-max，等于只开了门却锁着楼道和大门。
