LR做负载测试要监控服务器什么，重点看哪些性能指标？

lr做负载测试要监控服务器什么？一句话给结论：把CPU、内存、磁盘IO、网络四类资源全部纳入监控，并且不能只看平均使用率，要重点盯住队列长度、换页频率、IO等待时间和丢包重传，这些才是暴露瓶颈的先行信号。

为什么LoadRunner负载测试监控服务器资源不能只看TPS和响应时间

LoadRunner场景跑起来后，Controller界面最先跳出来的是事务平均响应时间、TPS、并发用户数，很多测试脚本一停在这里，看到TPS上不去、响应时间变大，就开始反复调脚本参数,这样定位问题基本靠猜。

服务器在压力下的真实状态，藏在操作系统计数器里，TPS下降和响应时间上升只是现象，同一现象可能对应完全不同的原因：CPU队列堆积、内存换页过度、磁盘IO排队、网络重传，不把这些资源分开看，很容易把磁盘慢当成CPU问题,或者把网络抖动当成应用逻辑慢。

行业内其实有个共识：负载测试中服务器资源监控必须和事务指标同步进行，否则性能结果缺少可解释性。 这不是为了多采几组数字，而是为了在响应时间变差的第一时间,知道该找谁。

lr做负载测试要监控服务器哪些指标？四类资源一个都不能漏

CPU：总使用率只算入门，队列长度才是关键

CPU监控至少看这几项：

• 总CPU使用率，注意区分用户态和内核态
• 每个逻辑核心的使用率，避免被平均值骗过去
• 处理器队列长度，这个值说明有多少任务在等CPU
• 上下文切换次数，过高会吃掉大量内核处理时间
• CPU时间中系统中断和DPC占用情况

判断CPU瓶颈的实用方法：当处理器队列长度持续大于逻辑核数，并且用户态CPU使用率已经贴近高点，响应时间同步升高，这时CPU就是明确瓶颈，只盯着“使用率90%”这种数字,在几十个核的服务器上很容易误判。

内存：可用内存不是唯一标准，换页和缓存同样重要

内存监控重点看：

• 可用内存数量
• 页换入和换出频率
• Swap使用量和Swap换页活动
• 文件系统缓存占用情况
• 进程工作集变化

可用内存减少不一定代表问题，多数情况下，操作系统会主动用空闲内存做文件缓存，真正危险的是持续出现大量页换出，或者Swap使用量线性增长且伴随换页活动升高，这说明物理内存已经满足不了工作集，服务器开始频繁用磁盘当内存，LoadRunner场景中如果出现内存持续下降后突然稳定但TPS下滑,往往就是开始换页的信号。

磁盘IO：平均等待时间和队列长度比读写速度更早暴露问题

磁盘监控别只盯着读写吞吐量：

• 每秒读写IOPS
• 磁盘吞吐量



• 平均单次IO等待时间
• 磁盘队列长度
• 磁盘利用率

一项常用的判断依据是：磁盘利用率长时间接近饱和值，平均单次IO等待时间显著增大，就说明磁盘已经处理不过来，即使吞吐量数字看起来还行，只要IO等待变长，事务响应时间一定会被拖累，尤其是数据库服务器、文件服务器和日志频繁落盘的场景。

网络：丢包重传容易被忽略，却是性能隐性杀手

网络层面要监控：

• 每秒收发包数量
• 网络吞吐量
• 连接数变化
• 丢包计数和重传计数
• TCP连接状态分布

负载测试中网络问题不一定出在带宽不够，相当一部分性能抖动，来自交换机端口错误、网卡队列打满或防火墙连接跟踪表耗尽，只要发现提交TPS和服务器实际处理数对不上，或者批量场景中偶发超时，先看丢包、重传和连接状态,往往比查应用日志更快。

下面这张表把四类资源的核心关注点放在一起,方便对比：

LoadRunner负载测试监控服务器资源：Windows和Linux实操差异

LR监控Windows服务器需要开启什么服务才能采到数据

很多新手在Controller里添加Windows服务器时，会碰到计数器没有数据或者报错,问题几乎都出在远程服务没开全。

LoadRunner通过Windows的远程监控接口读取计数器,目标机器至少需要确认几个服务：

• Remote Registry服务已启动，并且启动类型设置为自动
• Windows Management Instrumentation服务正在运行
• Server服务正常
• Performance Logs and Alerts服务没有禁用

可以在目标服务器上打开services.msc，逐项检查,更直接的验证方式是在Controller机器上执行：

wmic /node:目标IP /user:管理员账号 /password:密码 os get FreePhysicalMemory

这条命令能返回内存数字，说明WMI和远程访问基本打通，如果命令卡住或提示拒绝访问，先别怀疑LoadRunner，八成是Remote Registry没开，或者防火墙把RPC/WMI端口拦了。

Controller中添加监控的路径是：

Run标签页 -> Available Graphs -> System Resource Graphs -> Windows Resources

右键选择Add Measurements，输入目标服务器IP，平台选Windows，再添加计数器,加载时需要目标机器的管理员权限账号。

Linux服务器负载测试监控命令怎么用

LoadRunner监控Linux服务器，多数情况下需要目标机器运行rstatd服务，先在Controller里添加UNIX Resources测量，输入IP，如果能拉到默认指标，说明rstatd正常，如果没有数据,登录Linux服务器执行：

rpcinfo -p 服务器IP | grep rstatd

没有rstatd的话，基于RHEL/CentOS的发行版通常需要安装rpc.rstatd，基于Debian/Ubuntu的发行版通常安装rstatd，具体包名以实际仓库为准,安装后启动相关rpc服务并确认防火墙放行。

如果只是本地采集，不用LoadRunner远程拉取,下面几条命令足够覆盖主要资源：

vmstat 1 30
iostat -x 1
sar -u -r -d 1 10
sar -n DEV 1 10
dstat -c -m -d -n 1 30

vmstat里重点看r列和b列，分别代表运行队列和阻塞任务数。iostat -x里看%util和await。sar -n DEV看每块网卡的收发包和错误计数，这些命令可以直接在压测过程中开终端跑,不需要额外图形界面。

负载测试中服务器cpu多少正常？判断基准要结合场景

CPU没有固定正常值，只有“是否排队的区别”

负载测试中服务器cpu多少正常这个问题，没有统一数字，计算密集场景里，CPU总使用率长时间接近满载，但处理器队列长度很低，响应时间稳定，这种状态完全可以接受，反过来，有些场景CPU总使用率只有六成上下，但队列长度持续超过逻辑核数，响应时间不断上升,这就是CPU调度不过来的典型表现。

所以判断CPU是否正常,顺序应该是：

• 先看处理器队列长度，而不是总使用率
• 再看单核是否严重不均衡
• 最后结合上下文切换次数，判断是否频繁打断正在执行的任务

内存、磁盘、网络的判断基线同样要看趋势

内存不能只看某一瞬间可用值，要观察场景运行期间的趋势线，可用内存长期稳定在低位，但换页活动不增长，说明系统在正常吞掉缓存，可用内存低位且页换出持续增长,就需要停下来查哪个进程在膨胀。

磁盘基本判断原则是：等待时间短、队列短，就算吞吐高也不是问题；等待时间长、队列排队，即使IOPS不高也要优先处理，网络方面，吞吐量接近带宽上限只是说明带宽吃紧,丢包和重传增长才意味着链路质量或设备处理能力有问题。

负载测试中服务器监控的标准操作步骤模板

压测前先采基线

场景正式加压前，先让被测服务器空载运行5到10分钟，用同样一组计数器记录CPU、内存、磁盘、网络数据，这个基线用于后续对比，避免把服务器自身定时任务、备份进程造成的波动当成压测问题。

压测中按梯度记录

负载逐级上升时，每提升一个并发台阶，至少稳定观察3到5分钟，再记录一组关键指标，不要只看场景结束后的平均值,梯度过程中的瞬时变化往往更能说明瓶颈出现在哪个阶段。

压测后做差值分析

场景结束后，把每级负载下的资源数据与基线做差，优先筛选出增长最明显的几项，再看这些项是否和TPS下滑、响应时间升高的时间点重合，如果多条曲线在同一个时间点拐头,基本就能锁定主要瓶颈。

监控服务器资源时最容易踩的四个误区

• 只采集平均使用率，不看峰值和队列
• 监控采样间隔过长，比如5分钟才采一次，漏掉问题
• 把LoadRunner压力机和被测服务器装在同一台机器，监控数据互相干扰
• 只监控应用服务器，忽略数据库、缓存、消息队列所在机器的资源

排查顺序建议固定成：CPU队列 -> 内存换页 -> 磁盘等待 -> 网络丢包，这个顺序覆盖了大多数后端性能瓶颈的出现概率,定位效率比一项一项乱猜高得多。

Q&A：lr做负载测试要监控服务器什么

问：lr做负载测试要监控服务器哪些指标最优先？

答：优先监控CPU处理器队列长度、内存换页频率、磁盘平均等待时间和网络丢包重传，这些指标比平均使用率更早暴露排队现象，并发用户增加时，只要有一个资源开始排队,事务响应时间就会迅速变长。

问：LR监控Windows服务器需要开启什么服务才能正常取数？

答：至少需要Remote Registry、Windows Management Instrumentation、Server、Performance Logs and Alerts几个服务处于运行状态，同时要在防火墙放行RPC和WMI相关端口，最直接的验证办法是用wmic /node:目标IP /user:管理员账号 /password:密码 os get FreePhysicalMemory测试远程WMI是否畅通。

问：负载测试中服务器cpu多少正常？

答：CPU没有统一正常值，如果处理器队列长度持续大于逻辑核数，同时响应时间增长，说明CPU出现排队瓶颈，如果队列长度低，即使总使用率接近满载，也不一定需要立刻处理，判断CPU问题要结合队列长度、内核态时间和上下文切换次数,不能只凭使用率一个数字下结论。

服务器监控最终不是为了采数字，而是为了在响应时间变差时，能立刻找到资源排队的位置。把CPU、内存、磁盘、网络四个方向都盯住，负载测试结论才不会停在表面。