LR做负载测试时监控服务器，核心作用就是帮你揪出性能瓶颈的“真凶”到底是代码写的烂、服务器配置不够，还是数据库拖后腿，监控数据就是判案依据。具体要盯CPU、内存、磁盘I/O、网络带宽、数据库连接数这几项，配合并发用户曲线一起看,才能定位问题。
负载测试中监控服务器到底为了什么
很多团队跑LoadRunner压力测试，只盯着响应时间和错误率，服务器监控却草草了事，结果系统一慢，谁也说不清慢在哪，监控服务器，不是走形式,而是解决两个实际问题。
区分客户端瓶颈和服务器端瓶颈
压测时TPS上不去，响应时间飙升，可能是服务器资源耗尽，也可能是LoadRunner脚本本身有瓶颈，比如思考时间设太短、集合点不合理，导致客户端把服务器打挂了，没有服务器数据，你无法判断是服务器“撑不住”还是压力机“乱来”，只有看到CPU飙到95%以上、内存持续增长,才能断定是服务器端出了问题。
让调优方向有据可依
压测的目的不是找崩溃，而是提前发现隐患，服务器监控数据能告诉你：CPU吃紧是算法低效还是线程争抢？内存上涨是泄漏还是缓存策略不合理？磁盘I/O高是日志写太多还是数据刷盘太频繁？这些答案,全部藏在监控曲线里。
loadrunner监控服务器性能指标有哪些
这是最基础的一步，但很多人只加了个CPU和内存就开跑，完整的服务器监控,至少覆盖四个维度。
CPU使用率要看的不是平均值
LoadRunner的Windows监控面板默认采集% Processor Time，但别被平均值骗了，如果四核CPU平均50%，但其中一个核已经100%，照样会拖慢性能，建议同时监控Processor Queue Length（处理器队列长度），这个值持续大于2，说明CPU已经忙不过来，Linux服务器则看top里的load average,数值超过CPU核数就是过载信号。
内存与分页指标怎么解读
Windows监控Available MBytes
和Pages/sec，可用内存低于10%，或者Pages/sec持续高于20，意味着系统在疯狂换页，内存明显不够，Linux下重点看free -m的available列，以及vmstat里的si、so，这两项如果经常大于0，说明物理内存不足，SWAP已经介入,响应时间会直线上升。
磁盘I/O和网络吞吐量别忽略
磁盘监控看Avg. Disk Queue Length，持续高于磁盘数量乘以2，就是瓶颈，比如一块盘，队列长度超过2就危险，网络看Bytes Total/sec，对比带宽上限，如果接近80%，带宽就是天花板，这里有个常见坑：压测场景大多在内网，千兆网卡很容易被忽视，但结果就是吞吐量上不去,报表里还显示零错误。
lr做负载测试监控服务器cpu内存用什么方法
LoadRunner自带的监控功能够用，但想看得更细，得混合使用系统原生命令,下面给出现成方案。
使用LR自带的监控面板快速上手
Controller里右键点击“Available Graphs”，选择“Windows Resources”或“Unix Resources”，填上服务器IP和登录凭据，就能拉出CPU、内存、磁盘、网络四个模块，注意LoadRunner 12.60以上版本对Windows服务器的远程监控需要开启Perfmon权限,否则数据会是一片空白。
配合系统工具交叉验证
LR监控采集频率默认是10秒一次，偶尔会丢数据点，建议同时开一个nmon（Linux）或PerfMon（Windows）记录日志，压测完成后，用LR的曲线看整体趋势，再用系统工具的秒级数据确认细节，行业共识认为，压测监控至少需要双通道验证,单靠LR面板容易漏掉瞬时峰值。
监控命令实操清单
- Windows服务器：用
typeperf "\Processor(_Total)\% Processor Time" -sc 600 -si 1采集600秒每秒一次的数据，线程瓶颈看wmic path Win32_PerfFormattedData_PerfProc_Thread get Name,PercentProcessorTime。 - Linux服务器：
top -b -n 120 -d 1记录两分钟进程级CPU内存，内存变化用
vmstat 1 120
iostat -x 1 120。 - 数据库服务器：额外监控
sqlplus里的v$session_wait，别只看系统资源，很多项目在压测时发现CPU不高，但数据库锁等待严重,一样让服务器响应变慢。
服务器监控的常见误区和避坑指南
监控数据采集了一大堆，不会解读等于白测,下面三个坑几乎每个项目都会踩。
只看平均值，忽略峰值曲线
CPU平均值50%，看着挺健康，但曲线如果呈锯齿状，说明服务在“抽搐”一会儿忙到100%，一会儿空闲，这种状态比稳定高负载更伤用户体验，分析时鼠标悬停曲线，查看最大和最小值的差值，差值超过30%就要警惕。
监控间隔设置太粗
LR默认10秒采样一次，如果你把场景运行时间设为5分钟，只有30个数据点，碰到瞬间的请求堆积，曲线根本显不出来，把间隔改成1秒或2秒，虽然数据文件变大,但分析拐点时有颗粒度可言。
忘记监控应用服务器和数据库
许多人只监控操作系统层面的指标，忽略了中间件和数据库。大型压测项目中，数据库连接数耗尽比CPU跑满更常见，监控Tomcat时加JVM堆内存和GC频率，监控MySQL时看Threads_connected和Innodb_row_lock_current_waits，这些指标在LR自带的Diagnostics里没有,得单独装插件或写SQL查。
如何利用监控数据定位真正的性能瓶颈
数据齐了，最后一步是分析，别急着东看一块西看一块,按下面顺序排查。
先从资源曲线找拐点
打开LR的“Transaction Response Time”图，和CPU/内存曲线叠在一起看，如果响应时间在并发数升到200时急剧上升，同时CPU也到100%，那就是计算资源瓶颈，如果CPU只有30%，但响应时间已经飙高，问题多半在锁、数据库或网络延迟。
再关联并发用户数和资源消耗
画出“用户数-资源使用率”散点图，理想情况是资源随用户线性增长，但实际往往是先平缓后陡增，那个陡增的拐点，就是系统的最大支撑并发，用户数从100到200，CPU从20%涨到40%，正常，从200到250，CPU却从40%跳到90%，说明应用程序在线程调度上出了大问题,而不是物理资源不够。
最后区分软硬件瓶颈
如果CPU、内存、磁盘都正常，但系统吞吐量低，考虑是不是代码锁竞争、JVM参数不合理或者数据库连接池太小，这些软件问题在操作系统监控里看不到，需要结合应用日志，反过来，如果CPU长期100%，先把top里的进程拿出来，看是应用进程还是数据库进程,再决定升级配置还是优化SQL。
常见问题解答
LoadRunner监控不到远程服务器的Windows性能计数器怎么办？
检查三个地方：服务器防火墙是否放行TCP 135和445端口；Remote Registry服务是否启动；Controller端登录账户是否具备管理员权限，有时还需要在服务器上执行winmgmt /verify确认WMI服务正常。
压测时服务器CPU不高，但TPS上不去，是什么原因？
大概率瓶颈不在服务器硬件，而在应用自身，优先查数据库慢查询、中间件线程池配置、以及代码里有无串行化操作，用jstack抓一下Java进程线程状态，看有没有大量BLOCKED或WAITING线索。
监控数据要保存多久才算规范？
业内专家指出，性能测试监控数据应与测试报告一并归档，保存时长建议跟随项目周期，一般不少于一年,方便未来做容量规划或系统优化时翻出历史基线对比。
服务器监控不是压测的附属品，而是决定测试结论是否可信的基石，下次跑LoadRunner，别急着点“Start Scenario”，先把上面的指标和命令准备好，数据越细，定位越准，调优越省力，记住一句口诀：CPU看队列，内存看分页，磁盘看队列长度，网络看带宽余量，把这些盯住,LR压测才算真正测到了点子上。