Loadrunner如何监控服务器资源？-凌峰创科服务平台

LoadRunner 监控服务器的核心目标是：回答“为什么我的应用这么慢？”这个问题。

（图片来源网络，侵删）

下面我将从监控原理、监控对象、具体操作步骤、最佳实践四个方面，详细解释如何使用 LoadRunner 监控服务器。

监控原理

LoadRunner 本身不直接安装在服务器上收集数据,它的监控原理是：

Controller (控制器)：在 Controller 机器上，你启动一个“运行”。
添加监控目标：在 Controller 的“运行”视图中，你选择需要监控的服务器,并指定要监控的性能指标。
Agent (代理)：LoadRunner 会在被监控的服务器上安装一个轻量级的组件，称为 Analysis Agent 或 LoadRunner Agent，这个 Agent 负责收集本地操作系统的性能数据。
数据传输：Agent 将收集到的数据实时发送给 Controller。
数据展示：Controller 将接收到的数据以图表形式展示出来,让你可以实时观察服务器的健康状况。

重要提示：要成功监控，必须确保 Controller 机器与被监控的服务器之间网络通畅，Agent 能够正常启动和通信。

监控什么？（核心监控对象）

服务器性能监控主要关注四个方面，这也是 LoadController 提供的监控模板的核心：

（图片来源网络，侵删）

操作系统层

这是最基础也是最重要的监控层面,能告诉你系统资源的瓶颈在哪里。

Windows 服务器:
- Processor (处理器):
  - % Processor Time: CPU 总利用率。超过 70%-80% 就是一个警戒信号，持续高于 90% 通常意味着 CPU 瓶颈。
  - % User Time: 用户进程（如你的应用服务器、数据库）消耗的 CPU 时间，如果很高,说明应用本身计算密集。
  - % Privileged Time / % Interrupt Time: 系统调用和硬件中断消耗的 CPU 时间，如果很高,可能驱动或硬件有问题。
- Memory (内存):
  - Available MBytes: 可用物理内存，这是最直观的指标，如果持续下降并接近 0，说明内存严重不足，系统会开始使用虚拟内存（硬盘），导致性能急剧下降（颠簸现象）。
  - Pages/sec: 每秒从磁盘读取或写入到物理内存的页数。如果这个值持续很高（> 20），表明存在内存瓶颈,系统频繁地在内存和硬盘之间交换数据。
- Disk (磁盘):
  - Disk Time %: 磁盘忙碌时间。如果接近 100%，说明磁盘 I/O 是瓶颈。
  - Avg. Disk sec/Transfer: 平均每次磁盘传输所需时间，这个值越高，磁盘 I/O 性能越差。
  - Current Disk Queue Length: 当前磁盘请求队列长度，如果这个值持续大于物理磁盘数量 * 2,说明磁盘处理能力不足。
- Network (网络):
  - Bytes Total/sec: 网卡总流量（入站+出站），可以与 LoadRunner 的 Throughput（吞吐量）进行对比,看是否匹配。
Linux/Unix 服务器:
- CPU: us (user), sy (system), id (idle), wa (I/O wait)。us + sy 接近 100% 是警戒信号。wa 很高说明 I/O 等待严重。
- Memory: MemAvailable (可用内存) 或 free 命令，监控 Swap 的使用情况，Swap 被大量使用,说明内存不足。
- Disk: 监控磁盘的 util (利用率), await (等待时间), aqu-sz (队列长度)。util > 70% 或 await 过高都表明 I/O 瓶颈。
- Network: 监控 eth0 等网卡的 RX/TX (接收/发送) 字节速率。

Web/应用服务器层

这是你的应用运行的环境。

（图片来源网络，侵删）

Web 服务器 (如 IIS, Apache, Nginx):
- Requests/sec: 每秒处理的请求数，这是衡量 Web 服务器处理能力的基本指标。
- Bytes Sent/Received/sec: 网络流量。
- Active Server Sessions: 活动的服务器会话数。
- IIS: 可以监控 ASP.NET 请求的执行时间、错误数等。
应用服务器 (如 Tomcat, WebLogic, JBoss, WebSphere):
- JVM (Java 虚拟机) 监控:
  - Heap Memory Usage: 堆内存使用情况，监控 Eden, Old, Perm (或 Metaspace) 区的使用率。Old 区使用率持续接近 100% 是 Full GC (垃圾回收) 的前兆，会导致应用停顿，是严重的性能问题。
  - GC Count & GC Time: 垃圾回收的次数和耗时，频繁或耗时的 GC 会严重影响性能。
  - Thread Count: 线程数，如果线程数持续增长不释放,可能导致内存泄漏。
- 其他: 线程池使用情况、EJB 池状态等。

数据库服务器层

数据通常是应用的瓶颈所在。

通用指标:
- CPU Usage: 数据库服务器的 CPU 消耗。
- Memory Usage: 数据库缓冲池、缓存区的使用情况。
- Disk I/O: 数据文件和日志文件的读写速率。
特定数据库:
- Oracle:
  - 执行次数/秒: SQL 语句的执行频率。
  - 解析次数/秒: Hard Parse (硬解析) 非常消耗资源,应尽量减少。
  - 缓存命中率: Library Cache 和 Buffer Cache 的命中率,命中率低意味着频繁访问磁盘。
  - 等待事件: 如 db file scattered read (全表扫描), db file sequential read (索引读取), enq: TX - row lock contention (锁竞争) 等,通过等待事件可以精准定位数据库瓶颈。
- SQL Server:
  - Batch Requests/sec: 类似 Oracle 的执行次数。
  - SQL Compilations/sec & SQL Re-Compilations/sec: 重新编译过多会影响性能。
  - Buffer Cache Hit Ratio: 缓冲区缓存命中率。
  - Wait Stats: 如 PAGEIOLATCH_* (I/O 等待), LATCH_* (闩锁等待), CXPACKET (并行查询等待)。
- MySQL:
  - Questions / Queries: 每秒查询数。
  - Slow Queries: 慢查询日志中的数量。
  - InnoDB Buffer Pool Hit Rate / Usage: InnoDB 缓冲池使用率和命中率。
  - Threads_connected / Threads_running: 连接的线程数和活跃的线程数。

中间件层

消息队列 (如 RabbitMQ, Kafka):
- 消息生产/消费速率。
- 队列长度。
- 消息积压情况。

如何操作？（在 LoadRunner Controller 中）

启动 Controller 并创建场景：

打开 LoadRunner Controller,创建一个新的性能测试场景。
添加在线监控：
- 在 Controller 界面的左侧，找到并点击 “Online Measurements” (在线测量) 或 “Run” -> “Start Measurements”。
添加监控目标：
- 在弹出的窗口中，点击 “Add Measurements” (添加测量)。
- 选择服务器类型：从列表中选择你要监控的服务器类型，如 Windows Resources, Web Application Server, Oracle Database 等。
- 输入服务器信息：
  - Host Name/IP: 输入被监控服务器的 IP 地址或主机名。
  - Login Credentials: 输入具有管理员权限的用户名和密码。
- 选择监控指标：
  - 在右侧的列表中，勾选你关心的性能指标，对于 Windows，你可以勾选 % Processor Time, Available MBytes, Current Disk Queue Length 等。
  - LoadRunner 提供了预设的模板，如 Standard, Detailed，你可以直接选择一个模板,它会自动勾选一组关键指标。
- 点击 OK,服务器就会被添加到监控列表中。
启动场景和监控

Loadrunner如何监控服务器资源？

监控原理