负载生成器（Load Generator）无法连接故障诊断和修复手册

故障本质

负载生成器连接故障LoadRunner Controller在尝试和一台或多台指定的负载生成器建立管理和控制通道时失败。连接独立于测试脚本中模拟的用户流量，用于指令下发、状态监控和结果收集。故障发生时，Controller端一般报错：“Failed to connect to the load generator: [主机名/IP]” 或 “Cannot connect to the load generator”，负载生成器状态显示为“Down”。

通信流程

故障可发生于：

连接发起：Controller（运行在指定端口）向负载生成器主机的 TCP 50500 或 TCP 54345 端口（默认）发起连接。

服务响应：负载生成器上运行的 MILLoadRunnerAgent 或 Web Agent 服务负责监听并响应此连接。

认证和握手：建立连接后，进行根据主机名/IP、用户权限的认证。

建立会话：认证成功后，Controller分配任务，负载生成器启动 vuser 进程/线程执行。

系统化诊断途径

按照从基础到复杂，从外部到内部的原则进行诊断。

网络排查

在Controller主机上执行：

网络连通性测试：

ping <负载生成器主机名或IP>

结果A（失败）：表示存在物理网络中断、IP错误、主机离线或防火墙（ACL）阻断ICMP协议。

结果B（成功）：仅证明三层网络可达，不能保证业务端口开放。

业务端口连通测试：

telnet <负载生成器IP> 50500

结果A（连接被拒绝）：负载生成器端 50500 端口无服务监听。

结果B（连接成功，显示空白或字符）：端口可连通，基础网络无问题。

结果C（连接超时）：端口被中间防火墙或主机防火墙静默丢弃。

检查防火墙安全

主机防火墙：保证负载生成器主机（Windows防火墙、iptables等）已为Controller IP开放 TCP50500 及 TCP 54345端口。临时完全禁用防火墙可快速判断是不是为防火墙所致。

网络防火墙/安全组：在云环境或企业内网中，确定网络方面的安全组、ACL规则允许从Controller到负载生成器对应端口的流量。

防病毒软件：部分企业级防病毒软件的网络威胁防护功能可能拦截端口。尝试临时禁用后测试。

主机名和认证层排查

主机名

在Controller主机上执行 nslookup <负载生成器主机名>，记录分析出的IP地址。

登录负载生成器主机，执行 ipconfig /all（Windows）或 hostname -i（Linux），确定其本机识别的IP地址。

比对：两者必须一致。如果不，在Controller的 hosts 文件（C:\Windows\System32\drivers\etc\hosts）中建立静态映射：

<负载生成器真实IP>   <负载生成器主机名>

账户权限

LoadRunner Agent服务一般以特定账户运行。

Windows环境：

检查服务 MILLoadRunnerAgent 的“登录”属性。一般使用 “本地系统账户” 或一个专门的域账户。

如果使用域账户，保证密码未过期，且该账户在负载生成器主机上具有足够的本地权限。

操作：尝试将服务登录账户临时改为“本地系统账户”，重启服务后测试连接。如果成功，则为账户权限问题。

Linux/Unix环境：检查 mlagent 进程的运行用户，并保证Controller拥有通过RPC（或配置的认证方式）调用该用户执行任务的权限。

LoadRunner服务和配置排查

检查负载生成器服务状态

在负载生成器主机上，打开Windows服务管理器或使用命令：

sc query MILLoadRunnerAgent

确定服务状态为“RUNNING”。如果未运行，手动启动并观察事件查看器中的相关错误日志。

如果服务无法启动，检查其依赖项（如RPC服务）是不是正常。

Agent进程和端口监听

使用 netstat 命令确定端口监听正常：

netstat -ano | findstr :50500

应看到有进程正在监听 0.0.0.0:50500 或 <本机IP>:50500。记录PID。

如果端口未被监听，可能是：

Agent服务配置文件损坏。可尝试重启服务或重新安装Agent。

端口被其他应用程序占用。修改LoadRunner Agent配置，更换监听端口（需在Controller中同步修改连接配置）。

检查Controller端配置

在Controller的“负载生成器”配置界面中：

确定地址栏输入的是正确且可分析的主机名或IP。

平台选择：必须和负载生成器主机操作系统一致（如Windows， Linux）。

临时目录：保证指定的途径在负载生成器上存在且可写。

环境问题排查

检查系统资源和限制

Windows TCP/IP 连接数限制：高并发测试时，负载生成器本身可能耗尽临时端口。需调整注册表项 MaxUserPort 和 TcpTimedWaitDelay。

进程/线程数限制：保证系统允许Agent启动足够多的 vuser 进程/线程。

分析详细日志

启用LoadRunner的详细日志用来定位复杂问题。

在负载生成器上，编辑 MILLoadRunnerAgent 安装目录下的日志配置文件（如 agent.ini 或 mlagent.cfg），将日志级别调至DEBUG或VERBOSE。

重启服务，复现连接失败问题。

检查Agent日志文件（一般位于安装目录的 logs 子目录），搜索“ERROR”、“FAIL”、“reject”等重点词。错误信息会精确指出认证失败、资源不足或配置错误。

测试环境问题

IPv4/IPv6双栈环境：如果主机名优先分析到IPv6地址，但网络未配置完好，会导致连接失败。可在Controller的 hosts 文件中强制指定IPv4地址。

组方法和安全基线：企业级组方法可能禁用远程管理、限制服务权限或加固端口，需和IT安全部门协调。

时间同步：Controller和负载生成器主机时间差别过大，可能导致安全认证失败（如Kerberos）。保证所有机器时间同步。

修复

标准修复流程

保证网络连通和端口开放。

保证主机名分析和账户权限正确。

在负载生成器上，重启 MILLoadRunnerAgent 服务。

清除缓存在Controller中，移除有问题的负载生成器后重新添加。

每次只做一项变更，并立即测试连接，来隔离有效修复项。

在Controller中，右键点击负载生成器，选择“连接”。成功标志是状态从“Down”变为“Ready”，且“上次连接”时间更新。