一、 问题概述
部署于AArch64（ARM64） 架构Linux OS上的Jenkins Agent，通过 java11 -jar /root/agent.jar 命令以JNLP方式与Jenkins Master建立连接。该Agent主要用于在容器内执行RPM包编译任务。连接建立后极不稳定，频繁掉线，严重阻碍CI/CD流水线。
二、 连接原理与特定场景资源需求分析
1. 连接原理（JNLP over WebSocket）：
该方式非简单的HTTP连接，其核心是一个基于Java WebSocket的持久化、双向通信通道：
- 启动与注册：Agent启动后，通过HTTP GET请求从Master获取JNLP（Java Network Launching Protocol）配置文件。
- 认证与握手 ：Agent使用预共享的Secret Key进行认证，并与Master的特定端口（默认50000）建立一条长连接的WebSocket通道。
- 指令与数据传输 ：Master通过此通道向Agent发送执行指令（如启动构建）。构建日志、执行结果则通过此通道实时回传至Master。连接维持依赖于周期性的心跳包（ping/pong）。
2. 特定场景（容器内编译RPM）资源需求分析：
由于任务是在容器内编译RPM，其资源消耗远高于普通任务，是掉线的潜在诱因。
-
空间占用（Disk）：
- 基础占用 ：
agent.jar（~几十MB）、Jenkins工作目录。 - 主要占用 ：
- 容器镜像层 ：RPM编译通常需要
centos:7、rockylinux:9等基础镜像，单镜像体积可达数百MB。若未定期清理，多个版本的镜像会快速耗尽磁盘空间。 - 编译工作空间 ：RPM构建涉及源码、spec文件以及解压后的所有源码文件。编译过程中会产生大量的中间对象文件（
.o）和最终生成的rpm、srpm包。
- 容器镜像层 ：RPM编译通常需要
- 风险点 ：磁盘写满是导致Agent进程崩溃、构建失败、连接断开的常见原因。I/O等待过高也会影响心跳响应。
- 基础占用 ：
-
内存占用（Memory）：
- Agent进程 ：
java -jar agent.jar本身需要约128-512MB堆内存。 - 核心消耗 ：容器内的编译过程 。编译工具链（如
gcc,g++）处理大型源码时内存需求巨大。例如，编译大型C/C++项目时，单个g++进程占用数GB内存是常态。 - 风险点 ：物理内存不足会触发内核的OOM Killer（内存溢出杀手），它可能随机杀死Java Agent进程或容器内的编译进程，导致连接突然中断。
- Agent进程 ：
-
带宽要求（Network）：
- 连接维持：心跳包所需带宽可忽略不计。
- 主要消耗 ：
- 拉取容器镜像：每次构建可能都会拉取最新镜像，占用大量带宽。
- 下载源码与依赖：从Git拉取代码，从yum仓库下载Build-Depends（编译依赖包）。
- 风险点 ：网络带宽打满或高延迟会导致心跳包超时，Master误判Agent离线并将其断开。
-
CPU占用（CPU）：
- 核心消耗 ：容器内的代码编译。编译是极度CPU密集型操作，会使CPU利用率长时间保持100%。
- 风险点：CPU资源竞争可能导致Agent处理心跳包的线程被调度延迟，无法及时响应，引发超时断开。
三、 连接断开排查手段（由易到难）
1. 基础资源排查（第一步）
- 磁盘空间 ：在Agent节点执行
df -h，重点关注/和/var/lib/docker（Docker工作目录）的使用率。 - 内存与Swap ：执行
free -h或top，观察是否已无可用内存，Swap是否被大量使用。 - CPU负载 ：执行
top，查看CPU idle是否长期为0，负载负载平均值（load average）是否远高于CPU核心数。
2. 网络质量排查
- 稳定性与延迟 ：在Agent节点向Master执行长ping，观察丢包和延迟：
ping -c 100 <Jenkins_Master_IP> - 端口连通性 ：确认Master的Agent端口（默认50000）开放：
nc -zv <Jenkins_Master_IP> 50000
3. 日志分析（最关键步骤）
-
启用详细日志 ：重启Agent进程，添加详细日志参数并输出到文件。
bashjava -jar /root/agent.jar ... -loggingLevel finest > /tmp/agent.log 2>&1 -
搜索错误关键词 ：
IOException: Connection reset by peer/SocketException：网络问题或防火墙中断连接。Read timed out：网络延迟或Master高负载。ping failed/The channel closed：心跳失败的直接证据。OutOfMemoryError：内存不足，Java进程崩溃。No space left on device：磁盘已满。
4. 系统日志排查
-
检查系统日志，看是否有OOM Killer记录：
bashgrep -i 'killed process' /var/log/messages # 或 dmesg -T | grep -i kill如果输出中出现了Java或Docker相关进程被杀死，即可确诊。
5. AArch64架构特定考量
- Java版本 ：确认使用的是AArch64版本JDK：
java -version输出应包含aarch64字样。推荐使用Azul Zulu或Eclipse Temurin的AArch64 JDK。 - 容器平台 ：确保Docker或Podman已支持AArch64架构，且拉取的基础镜像也是AArch64版本 （如
rockylinux:9-aarch64），避免因模拟运行导致的性能问题和莫名崩溃。
四、 稳定性优化与建议
-
资源保障：
- 为Agent机器预留充足的资源缓冲区（如内存、CPU核心）。
- 设置Docker镜像和容器自动清理策略（
docker system prune -a --volumes -f可加入定时任务，但需谨慎）。 - 监控磁盘使用率，设置报警。
-
进程守护 （强烈推荐 ）：
使用Systemd守护Agent进程，实现崩溃后自动重启。
bash# /etc/systemd/system/jenkins-agent.service [Unit] Description=Jenkins Agent (RPM Builder) After=network.target docker.service [Service] User=root ExecStart=/usr/bin/java -Xms512m -Xmx1024m -jar /root/agent.jar -jnlpUrl ... -secret ... -workDir "/jenkins" Restart=always RestartSec=30 TimeoutStopSec=90 [Install] WantedBy=multi-user.target使用
systemctl daemon-reload和systemctl enable --now jenkins-agent启用。 -
连接方式优化 ：
考虑改用SSH Agent方式连接，SSH协议在恶劣网络环境下比JNLP更稳定。
-
优化构建流程：
- 在Dockerfile中使用多阶段构建，减少最终镜像体积。
- 使用本地yum仓库镜像或缓存代理（如
nexus）来缓存编译依赖，减少网络拉取时间和带宽占用。
五、 总结
AArch64架构下运行高负载的RPM编译任务，对Agent节点的稳定性是极大考验 。频繁掉线通常是系统资源（内存、磁盘）耗尽 、网络超时 或进程因故被杀死 所致。排查应遵循 "资源 -> 网络 -> 日志 -> 系统事件" 的路径。最终，通过资源扩容 、Systemd守护 和构建流程优化三管齐下，能极大提升该节点的连接稳定性。