lr做负载测试要监控服务器什么用，lr负载测试监控哪些指标

在LoadRunner负载测试中，监控服务器的CPU、内存、磁盘I/O、网络吞吐量以及数据库连接池等资源指标，是判断系统瓶颈和稳定性的核心依据，这些数据直接呈现服务器在压力下的真实状态。

为什么负载测试必须监控服务器资源

负载测试模拟用户并发，但用户端响应时间变慢，原因可能出在服务器资源不足，只有盯着服务器指标，才能把瓶颈锁定在具体层面是CPU计算不过来，还是内存不够导致频繁交换，或是磁盘读写卡住，亦或是网络带宽被占满，行业共识认为，没有资源监控的负载测试就像闭眼开车,只知道速度但看不见路况。

服务器资源监控能把“黑盒”变成“白盒”，当压力增加时，各个资源的变化曲线与事务响应时间曲线放在一起，立刻就能看出哪个资源先到达极限，从而指导优化方向，否则，你只能猜测问题出在代码、数据库还是配置上。

lr负载测试监控服务器指标详解

CPU使用率与队列长度

CPU是服务器的发动机，在负载测试中，监控% Processor Time和System Processor Queue Length，如果CPU使用率持续高于75%且队列长度长期大于2，说明CPU已经饱和，请求在排队等待处理，此时事务响应时间往往会迅速上升，如果CPU使用率不高但响应慢,则瓶颈可能在别处。

实际场景：某电商网站在促销活动压测时，CPU瞬间飙到95%，用户点击下单后卡顿明显，通过监控发现CPU满载，优化点在于代码中的循环计算和序列化操作，改为异步处理后CPU降至60%以下。

内存利用率与页面交换

内存不足时，操作系统会借用磁盘空间做虚拟内存，导致性能急剧下降，监控Available MBytes和Pages/sec，如果可用内存持续低于总内存的10%且页面交换频繁，说明内存压力大，在长时间负载测试中，内存占用一直增长不回落,往往存在内存泄漏。

行业共识：内存泄漏在短期测试中不易发现，建议至少运行1小时以上的压力场景,并监控内存曲线的趋势。

磁盘I/O性能

磁盘是数据库和文件密集型应用的常见瓶颈，监控Avg. Disk Queue Length和Disk Read/Writes Per Second，队列长度长期超过2表明磁盘跟不上请求，如果磁盘等待时间很高，CPU却空闲，说明I/O在等待磁盘完成操作。

举例：一个日志系统在并发写入时，磁盘队列长度飙到8，事务响应时间从10ms变成500ms，更换SSD后队列长度降到1以下,响应时间恢复。

网络吞吐量与延迟

网络带宽饱和会直接导致丢包和重传，增加延迟，监控Bytes Total/sec，与网卡带宽上限对比，如果利用率超过80%，考虑网络瓶颈，丢包率也是重要指标,尤其是在跨地域部署的场景。

数据库与中间件指标

除了操作系统，应用服务器和数据库的状态直接影响业务，需要监控数据库连接池使用率、活跃会话数、慢查询数量，使用LoadRunner的数据库监控模板或直接查询数据库视图，如果连接池占满，新请求就会排队等待,反映在响应时间上就是突然变慢。

实操路径：在Controller中通过“添加度量”选择数据库计数器,或使用自定义SQL脚本每隔几秒抓取关键指标。

如何使用LoadRunner监控服务器资源

LoadRunner Controller内置资源监控功能，支持Windows/Linux/Unix,也支持通过SiteScope集成。

监控Windows服务器

• 在Controller中右键“Resources”->“添加度量”。
• 选择“Windows”类型,输入服务器IP和凭据。
• 添加计数器：处理器% Processor Time、内存Available MBytes、物理磁盘Avg. Disk Queue Length

  、网络接口Bytes Total/sec。

  

• 设置轮询间隔，建议5-10秒,避免监控本身影响性能。

监控Linux服务器

• 在Linux服务器上启动rstatd服务（sudo service rstatd start）,或使用SSH监控。
• 在Controller中添加“Unix”度量，输入IP,选择计数器。
• 如果使用SSH模式，需要配置免密登录，计数器列表会变成类似CPU、Memory、Disk的形式。

监控数据库

• 使用LoadRunner的“数据库监控”模板，选择数据库类型（Oracle、SQL Server等）,输入连接信息。
• 也可以自己在场景中插入lr_db_connect命令,并记录关键SQL的响应时间。
• 对于MySQL，可以监控Threads_connected、Innodb_row_lock_current_waits等状态变量。

数据分析和瓶颈定位

拿到监控数据后，不能只看平均值,要结合曲线趋势。

关联资源与事务曲线

• 将CPU曲线和事务响应时间曲线叠加，如果CPU在达到100%时响应时间突然变长,CPU就是瓶颈。
• 如果内存曲线持续上升但响应时间不变，可能内存尚足,但需要留意是否泄漏。
• 磁盘队列长度与响应时间同步上升，说明I/O瓶颈。

典型场景分析

• CPU瓶颈：并发增加，CPU使用率线性上升直到饱和，响应时间随之非线性增长,此时优化代码或增加CPU核心数。
• 内存瓶颈：可用内存持续下降，页面交换频繁，响应时间波动大,建议增加内存或排查内存泄漏。
• 磁盘I/O瓶颈：CPU使用率不高，但磁盘队列很长，响应时间大部分花在I/O等待，优化SQL、增加缓存或换用SSD。
• 网络瓶颈：网络吞吐量接近带宽上限，丢包率升高，响应时间增加,考虑压缩数据或升级带宽。

常见误区与注意事项

• 只关注平均负载，忽略峰值：平均负载正常不代表压力尖峰时系统不崩溃,要观察曲线最高点。
• 监控指标太多：每个计数器都会消耗资源，建议只监控最关键的5-8个指标,不影响测试结果。
• 不验证监控配置：测试开始前务必确认监控数据在实时刷新，否则测试结束后才发现没有数据,等于白做。
• 忽略系统级进程：有时杀毒软件或备份进程突然占用CPU，导致测试结果异常,可以监控进程级CPU使用率来排除干扰。

Q&A：负载测试服务器监控常见问题

问：lr做负载测试要监控服务器什么用？

答：监控服务器资源是为了量化系统在压力下的表现，定位瓶颈是CPU、内存、磁盘还是网络，从而确定优化方向，没有监控，测试结果只能说明“快或慢”，但不知道原因,资源监控是性能分析的基础环节。

问：LoadRunner监控服务器需要额外安装软件吗？

答：监控Windows通常不需要额外软件，依靠WMI即可，监控Linux需要安装rstatd或配置SNMP/SSH，如果使用SiteScope，则功能更强大但需要单独许可,数据库监控通常也需要对应的驱动或客户端。

问：监控数据是实时显示还是测试后分析？

答：Controller可以实时显示资源曲线，同时数据会保存到结果文件中供Analysis工具事后分析，建议实时观察，以便在测试过程中发现异常立即调整场景或停止测试,避免无效运行。

在负载测试中，监控服务器资源是将性能问题从主观感受变为客观数据的关键一步，当你盯着CPU、内存、磁盘和网络的曲线，结合事务响应时间的变化，每一次优化都有据可依,系统承载能力也就在这些数字的指引下稳步提升。