LoadRunner如何监控Linux与Windows

监控 windows 系统

　　1、监视连接前的准备 工作

　　1）进入被监视windows系统，开启以下二个服务Remote Procedure Call(RPC) 和RemoteRegistry Service (开始—)运行 中输入services.msc，开启对应服务即可)。

　　2）在被监视的WINDOWS机器上:右击我的电脑,选择管理->共享文件夹->共享 在这里面要有C$这个共享文件夹(要是没有自己手动加上)。

　　3）在安装LR的机器上，开始—》运行，输入 \\被监视机器IP\C$然后输入管理员帐号和密码,如果能看到被监视机器的C盘了,就说明你得到了那台机器的管理员权限,可以使用LR去连接了。（LR要连接WINDOWS机器进行监视要有管理员帐号和密码才行。）

　　问题：在执行步骤3）时，输入\\被监视机器IP\C$，出现不能以administrator身份访问被监控系统（若采用这种方式用LR对其监控的话，会提示：“找不到网络路径”）的情况，现象就是用户名输入框是灰色的，并且默认用户是guest。

　　解决办法：这是安全策略的设置问题（管理工具 -> 本地安全策略 -> 安全选项 -> "网络访问：本地帐户的共享和安全模式"）。默认情况下，XP的访问方式是"仅来宾"的方式，如果你访问它，当然就固定为Guest来访问，而guest账户没有监控的权限，所以要把访问方式改为“经典”模式，这样就可以以administrator的身份登陆了。修改后，再次执行步骤3），输入管理员用户名和密码，就可以访问被监控机器C盘了

　　看看computer browser服务是否开启？开启computer browser

　　最后把windows 2003上的域控制器删除掉，解决问题了。

　　不知道域控制器哪里的设置影响到，使得lr监控不到系统资源。

　　试过把域控制器里的administrator里有关权限的部分都设置为了允许还是监控不了。最后没辙，把域控制器给删除掉了。

　　有空再看看具体是域控制里哪里设置问题。

　　如何删除域控制器2008-02-29 07:46如何删除域控制器单击"开始"-->"运行"按钮，弹出"运行"对话框，输入"dcpromo"，单击"确定"按钮 --> 弹出"Active Directory删除向导" 窗口， 单击"下一步"；在"删除Active Directory"窗口中选定"这个服务器是域中的最后一个域控制器",单击"下一步"；弹出"网络凭证"窗口,在"用户名" 、密码"文本框中输入密码(建立活动目录时的密码),单击"下一步"；弹出"管理员密码"窗口,在"密码"及"确认密码"文本框中输入密码(同前),单击"下一步"；此时出现"摘要"信息，若一切正常，则单击 "下一步"；系统将根据您的选择，删除活动目录,经过几分钟之后,删除结束；在"完成Active Directory降级向导"窗口中,单击"完成",即完成活动目录的删除.重新启动计算机,删除活动目录即会生效

　　若这样都不行的话（可能是其它问题引起的），那只好采取别的方法了。在服务器的机子上，通过windows自带的“性能日志和警报”下的“计数器日志”中新增加一个监控日志（管理工具—）性能—）性能日志和警报），配置好日志，也能监控服务器的cpu、memory、disk等计数器。当然，这种方法就不是用LR来监控了。

　 　2、用LR监视windows的步骤

　　在controller 中，Windows Resources窗口中右击鼠标选择AddMeasurements，添加被监控windows的IP地址，选择所属系统，然后选择需要监控的指标就可以开始监控了。

　 　3、Windows 常用的计数器

　　Memory：Available Mbytes 物理内存的可用数（单位 Mbytes）至少要有10% 的物理内存值；如果Process/Private bytes 和 Process/working set这两个计数器升高但是Available Mbytes降低则可能存在内存泄漏。

　　Processor：%Processor Time CPU 使用率。这是查看处理器饱和状况的最佳计数器。显示所有 CPU 的线程处理时间。如果一个或多个处理器的该数值持续超过 90%，则表示此 测试的负载对于目前的硬件过于沉重。为多处理器服务器添加该计数器的 0 到 x 个实例。

　　Processor Queue Length：是指处理列队中的线程数，小于2。处理器瓶颈会导致该值持续大于2。

　　Context Switches/sec：如果切换次数到5000*CPU个数和10000*CPU个数中，说明它忙于切换线程。如果吞吐率降低且CPU使用率高，且Context Switches/sec在15000以上则可能应用程序忙于切换线程。

　　比较Context Switches/sec和%Privileged Time来判断上下文切换是否过量。如果后者的值超过40%，且上下文切换的速率也很高，那么应该检查为什么会产生这样高的上下文切换

　　Network Interface：Bytes Total/sec 为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。带宽10M=1.28MBps=1280kBps. Kilobytes per second （kBps.）Bytes Total/sec的计量单位是Bytes per second，该值与网络带宽相除应小于50%

　　Disk Time（Physical_disk_total），%DPC Time(Processor) & % Processor Time(Processor)，如果这三个计数器均较大，则磁盘不是瓶颈，如果只有Disk Time较大，其他适中则IO可能为瓶颈，另外，如果Disk Time保持在2.0以下且有超过3.0的磁盘队列长度（Current Disk Queue），则IO瓶颈。 Disk Bytes/sec??

　　page read/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。

　　Physical Disk\ % Disk Time

　　Physical Disk\ Avg.Disk Queue Length

　　例如，包括Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。

4. Web page breakdown

　　Average Transaction Response Time图形，对某个事物通过分解（breakdown）命令进一步分解方法：右键某事物，选择“Web Page break down for xxx”

　　说明：

　　LoadRunner用不同的颜色标识不同的操作所消耗的时间，可以分解的操作包括DNS Resolution、Connection、 SSL Handling、 FTP Authentication、 First Buffer、 Receive、 Client、 Error。

　　如果主要的时间消耗是DNS Resolution，则说明需要重点关注网络相关的因素；

　　如果主要的时间消耗在Receive上，则说明可以通过减小返回数据的大小（例如：在Net中取消 ViewState）或是改变网速减少影响时间。

　　如果主要的消耗在First Buffer，则可以根据进一步的分析确定具体的性能瓶颈。

　　DNS Resolution：

　　DNS解析时间,浏览器访问一个网站的时候，一般用的是域名，需要dns服务器把这个域名解析为IP，这个过程就是域名解析时间，如果我们在局域网内直接使用IP访问的话，就没有这个时间了

　　Connection：

　　解析出Web Server 的IP地址后，浏览器请求被送到了Web Server，然后浏览器和Web Server 之间需要建立一个初始化HTTP连接，服务器端需要做2件事：一是接收请求，二是分配进程，建立该连接的过程就是connection时间。

　　SSL Handshaking：

　　SSL 握手协议，用到该协议的页面比较少

　　FTP Authentication：

　　……

　　First Buffer：

　　建立连接后，从Web Server 发出第一个数据包，经过网络传输到客户端，浏览器成功接受到第一字节的时间就是First Buffer。这个度量时间不仅可以表示Web Server 的延迟时间，还可以表示出网络的反应时间（网络不好，或WebServer性能不好）

　　Receive：

　　从浏览器接收到第一个字节起，直到成功收到最后一个字节，下载完成止，这段时间就是receive时间

　　Client：

　　请求在客户端浏览器延迟的时间，可能是由于客户端浏览器的think time 或者客户端其他方面引起的延迟

　　Error：

　　从发送了一个HTTP 请求，到Web Server发送回一个HTTP 错误信息，需要的时间

　　为了确认问题的缘由到底是服务器还是网络，先察看“Time to First Buffer Breakdown”

　　 监控UNIX

　　一. lr监控UNIX ，UNIX先启动一rstatd服务

　　以下是在IBM AIX系统中启动rstatd服务的方法：

　　1. 使用telnet以root用户的身份登录入AIX系统

　　2. 在命令行提示符下输入：vi /etc/inetd.conf

　　3. 查找rstatd，找到#rstatd   sunrpc_udp     udp     wait    root    /usr/sbin/rpc.rstatd rstatd 100001 1-3

　　4. 将#去掉

　　5. :wq保存修改结果

　　6. 命令提示符下输入：refresh –s inetd重新启动服务。

　　这样使用loadrunner就可以监视AIX系统的性能情况了。

　　7. 补充一些常见的问题及处理方法：

　　1、在执行配置或安装命令过程中出现“拒绝的权限”的提示；

　　答：是由于文件的权限引起的，应该给当前用户所有文件的“777”权限，即完全控制权限。

　　2、安装好后从LoadRunner中看不到信息，但是没有报错；

　　答：可能是返回的信息值比较小，所以在图中几乎看不到，例如：如果没有运行程序的话，CPU的使用率接近于0，所以在监视图中看不到变化。也有可能是采样的频率过大，可以在图表中设置没1秒获取一次信息，这样界面就刷新的比较及时了。

　　3、监视一段时间后LoadRunner中提示有错误发生不能继续监视到信息；

　　答：可能是由于CPU长时间处于高负荷状态，而导致系统自动关闭了该服务。可以在LoadRunner中重新加一次计数器，并且设置取样的时间稍长一点，就会避免这种情况。

　　4、以前用LoadRunner监视都是成功的，但是再次监视不到信息；

　　答：有可能是由于系统重新启动，而没有打开rstatd守护进程。可以手工重新打开一次，使用命令“rpc.rstatd”，另外可以使用“rpcinfo-p”命令来查看当前系统是否已经启动了rstatd守护进程。

　　 二、在lr中配置

　　从LR里面add measurement，填写linux机器的IP，出现所有unix/linux的计数器，包括cpu的，mem的，disk，network的。介绍几个常用的：

　　CPU: 确定服务器的cpu个数

　　average load :在过去的1分钟的平均负载, 即在过去的1分钟处于就绪状态的平均进程数；

　　如果这个数字大于CPU的数据，至少有一个线程要等待CPU; 如果这个数除以CPU的数目，结果高于5的时候就表明系统在超负荷运转了.相当于执行vmstat查询出来的r列的值（runable threads，可运行的线程）

　　cpu utilization: cpu的使用率：Percent of time that the CPU is utilized.

　　System mode cpu utilization + User mode cpu utilization>80%， us>sys 2:1

　　内存：确定内存的值

　　paging rate： 每秒从磁盘读到物理内存，或者从物理内存写到页面文件的内存页数。如果页交换率提高，CPU消耗也相应增加

　　如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

　　相当于执行vmstat得出的pi和po的值之和

　　pi

　　每秒钟从内存交换区载入的页面数

　　po

　　每秒钟写入内存交换区的页面数

　　CPU用于vhand和swapper两中守护进程的时间(CPU time to vhand and swapper)

　　必须注意的是，有时候我们发现CPU很忙，这似乎是CPU资源成为系统性能的瓶颈，但如果进一步分析，发现vhand和swapper守护进程占用了大量的系统CPU时间，很显然，这时系统性能瓶颈真正所在可能是内存。

　　这个机制是由一个叫vhand的进程来完成

　　当可用内存的数量小于LOTSFREE时（即没有可用页），例程pageout将被调用来选择什么内存可以释放。

　　lotsfree: based on physical memory (64 MB -> 863) upper bound where paging starts/stops

　　desfree: based on physical memory (64 MB -> 215)lower bound where paging starts/stops

　　minfree: based on physical memory (64 MB -> 53) threshold where deactivation starts

　　如果不存在可用页，内存管理系统就必须选择其它进程仍在使用但短期内最不可能使用的页。需要 CPU 周期来选择这些页。定位此类页的过程称为页扫描。CPU 利用率在需要页扫描时会增加。

　　页面换出是关键因素，因为操作系统只有在找不到可用的页时才进行换页。

　　页扫描（寻找）的高速率进行可及早地为内存利用率正在变成瓶颈提供指示。

　　当 CPU 已经识别出可分拨的页时，通过将这些页中原有的数据复制到专用的磁盘中，从而换出原来的页映象。存储页映象的磁盘或磁盘分区称为交换磁盘、交换空间或交换区域。

　　Swap-in rate:每秒交换到内存的进程数

　　Swap-out rate: 每秒从内存交换出来的进程；

　　内存非瓶颈：swap-in/out =0

　　Disk traffic:disk传输率Rate of disk transfers.等价iostat –d  3  n 输出的tps或者iostat –x  3 中的 r/s+w/s

　　Tps：表示每秒钟输出到物理磁盘的传输次数。一次传输就是一个对物理磁盘的 I/O 请求

　　一般为100-150之间

　　collision rate=0

　　Network collision rate = Output collision counts / Output packets

　　网络冲突率大于10%就显示，网络负载过大、网络配置不正确、硬件问题

　　Input Packet Error Rate = Ierrs / Ipkts.

　　如果input error rate高（ver 0.25 percent），这个主机就正在丢包。hub/switch 连线就需要被检查是否存在潜在的问题。

　　CPU: topas 命令，如果%user+%sys >80%, 则cpu可能为瓶颈

　　显示10个消耗cpu最多的进程

　　ps aux | sort –rn +2 | head –10

　　MEM: topas

　　Real MeM: 8192

　　Paging space: 9728

　　%used 18.1

　　%free 81.8

　　如果%used>70%,内存成为瓶颈

　　显示10个消耗内存最多的进程

　　ps aux | sort –rn +3 | head –10

　　当内存资源成为系统性能的瓶颈时，它有一些典型的症状：

　　很高的换页率(high pageout rate):HP-UX是一个按需调页的操作系统，通常情况下，它只执行调入页面进入内存的操作，以让进程能够运行。只有操作系统觉得系统需要释放一些内存空间时，才会执行从内存调出页面的操作，而过高的调出页面操作说明内存缺乏；

　　进程进入不活动状态(process deactivation activity):当自由的内存页面数量小于MINFREE时，很多进程将强制进入不活动状态，因为，any deactivation activity represents a condition in which normal paging is inadequate to handle the memory demands.

　　自由内存的数量很小，但活动的虚拟内存却很大(very small free memory and large active virtual memory)

　　交换区所有磁盘的活动次数可高(high disk activity on swap devices)

　　可高的全局系统CPU利用率(high global system CPU utilization):

　　很长的运行进程队列，但CPU的空闲时间却很多(large run queue with idle CPU)

　　内存不够出错(out of memory errors)

　　CPU用于vhand和swapper两中守护进程的时间(CPU time to vhand and swapper)

　　必须注意的是，有时候我们发现CPU很忙，这似乎是CPU资源成为系统性能的瓶颈，但如果进一步分析，发现vhand和swapper守护进程占用了大量的系统CPU时间，很显然，这时系统性能瓶颈真正所在可能是内存。

　　IO

　　Iostat查看磁盘IO负载

　　如果%iowait>25%, %tm_act%>70%, 则io瓶颈？

　　Topas

　　Busy%==%tm_act%

　　%tm_act,或%busy > 80

　　%iowait显示了 CPU 空闲期间系统有未完成的磁盘 I/O 请求时的时间百分比。

　　NETWORK:

　　Topas: kBps（总流量）

　　服务器网络带宽：10Mbps=1250kBps

　　该值与当前网络带宽相除应小于50%

补充：

　　从步骤 1 开始，首先查看 CPU 使用情况，按照诊断 CPU、内存或磁盘瓶颈的指导进行操作。对于下面的每个步骤，查找一端时间内的趋势，从中收集系统运行性能较差时的数据。另外，只有将这些数据与系统正常运行时收集的数据进行比较时才能进行准确的诊断。

　　 步骤 1

　　# sar -u [interval] [iterations]

　　(示例: sar -u 5 30)

　　%idle 是否很低? 这是 CPU 未在运行任何进程的时间百分比。在一端时间内 %idle 为零可能是 CPU 瓶颈的第一个指示。

　　不是 -> 系统未发生 CPU 瓶颈。转至步骤 3。

　　是 -> 系统可能发生了 CPU、内存或 I/O 瓶颈。转至步骤 2。

　　 步骤 2

　　%usr 是否较高? 很多系统正常情况下花费 80% 的 CPU 时间用于用户， 20% 用于系统。其他系统通常会使用 80% 左右的用户时间。

　　不是 -> 系统可能遇到 CPU、内存或 I/O 瓶颈。转至步骤 3。

　　是 -> 系统可能由于用户进程遇到 CPU 瓶颈，查找占用大量cpu的用户进程,分析cpu瓶颈的原因

　 　步骤 3

　　%used的值是否大于70

　　是 -> 以后记住这个值。它可能表示内存瓶颈。查看占用大量内存的进程，分析内存瓶颈。转至步骤 4。

　　不是 -> 转至步骤 4。

　　 步骤 4

　　%wio 的值是否大于 15?

　　是 -> 以后记住这个值。它可能表示磁盘或磁带瓶颈。转至步骤 4。

　　不是 -> 转至步骤 4。

　　 步骤5

　　# sar -d [interval] [iterations]

　　用于任何磁盘的 %busy 是否都大于 50? (请记住，50% 指示一个大概的 指南，它可能远远高于您系统的正常值。在某些系统上，甚至 %busy 值为 20 可能就表示发生了磁盘瓶颈，而其他系统正常情况下可能就为 50% busy。)对于同一个磁盘上，avwait 是否大于 avserv?

　　不是 -> 很可能不是磁盘瓶颈，转至步骤 6。

　　是 -> 此设备上好像发生了 IO 瓶颈。

　　转至步骤 5。

　　步骤 5

　　系统上存在磁盘瓶颈，发生瓶颈的磁盘上有哪些内容?

　　原始分区，

　　文件系统 -> 转至部分 3，部分 B，调整发生磁盘 IO 瓶颈的系统。

　　Swap -> 可能是由于内存瓶颈导致的。

　　转至步骤 6。

　　 步骤 6

　　# vmstat [interval] [iterations]

　　在很长的一端时间内，po 是否总是大于 0?

　　对于一个 s800 系统 (free * 4k) 是否小于 2 MB，

　　(对于 s700 系统 free * 4k 是否小于 1 MB)?

　　(值 2 MB 和 1 MB 指示大概的指南，真正的 LOTSFREE 值，即系统开始发生 paging 的值是在系统引导时计算的，它是基于系统内存的大小的。)

　　不是 -> 如果步骤 1 中的 %idle 较低，系统则很可能发生了 CPU 瓶颈。

　　转至部分 3，部分 A，调整发生了 CPU 瓶颈的系统。

　　如果 %idle 不是很低，则可能不是 CPU、磁盘 IO或者内存瓶颈。

　　请转至部分 4，其他瓶颈。

　　是 -> 系统上存在内存瓶颈，转至部分 3 部分 C，调整发生内存瓶颈的系统。

　 　监控Linux

　　一、在服务器上安装rstatd守护进程

　　安装步骤：

　　1. 从网上下载rstatd

　　2. 将该文件放到/home/user目录下

　　3. chmod 777 rpc.rstatd----改变该文件读写的权限，拥有所有权限。

　　4. chmod 777 configure ---同上

　　5. ./configure ---配置

　　6. make ---编译

　　7. make install ---安装

　　8. rpc.rstatd ---启动rstatd进程

　　1 准备工作

　　1）首先,监视Linux一定要有rstatd这个守护进程,有的Linux版本里也有可能是rpc.rstatd这里只是名字不同而已,功能是一样的。一般来说LINUX需要下载一个包才有这个服务,包名字是rpc.rstatd-4.0.1.tar.gz.这是一个源码,需要编译,下载并安装rstatd（可以在http://sourceforge.net/projects/rstatd这个地址下载）

　　下载后，开始安装，安装步骤如下：

　　tar -xzvf  rpc.rstatd-4.0.1.tar.gz

　　cd  rpc.rstatd-4.0.1/

　　./configure  —配置操作

　　make —进行编译

　　make install —开始安装

　　rpc.rstatd —启动rstatd进程

　　2）安装完成后配置rstatd目标守护进程xinetd,它的主配置文件是/etc/xinetd.conf ,它里面内容是一些如下的基本信息：

# # xinetd.conf # # Copyright (c) 1998-2001 SuSE GmbH Nuernberg, Germany. # Copyright (c) 2002 SuSE Linux AG, Nuernberg, Germany. # defaults { log_type        = FILE /var/log/xinetd.log log_on_success  = HOST EXIT DURATION log_on_failure  = HOST ATTEMPT #        only_from       = localhost instances       = 30 cps             = 50 10 # # The specification of an interface is interesting, if we are on a firewall. # For example, if you only want to provide services from an internal # network interface, you may specify your internal interfaces IP-Address. # #       interface       = 127.0.0.1 } includedir /etc/xinetd.d

　　我们这里需要修改的是/etc/xinetd.d/下的三个conf文件 rlogin ,rsh,rexec这三个配置文件,打这三个文件里的disable = yes都改成 disable = no ( disabled 用在默认的 {} 中 禁止服务)或是把#default: off都设置成 on 这个的意思就是在xinetd启动的时候默认都启动上面的三个服务!

　　说明：我自己在配置时，没有disable =yes这项，我就将# default: off改为：default: on，重启后(cd /etc/init.d/     ./xinetdrestart)通过netstat -an |grep 514查看，没有返回。然后，我就手动在三个文件中最后一行加入disable =no，再重启xinetd，再使用netstat -an |grep 514查看，得到tcp 0 0 0.0.0.0:514 0.0.0.0:*LISTEN结果，表明rsh服务器已经启动。

　　只要保证Linux机器上的进程里有rstatd和xinetd这二个服务就可以用LR去监视了

　　两点小的技巧:

　　1)检查是否启动: rshserver 监听的TCP 是514。

　　[root@mg04 root]# netstat -an |grep 514

　　tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN

　　如果能看到514在监听说明rsh服务器已经启动。

　　2)检查是否启动: rstatd

　　输入命令: rpcinfo -p

　　如果能看到类似如下信息：

　　程序 版本 协议 端口

　　100001    5   udp    937  rstatd

　　100001    4   udp    937  rstatd

　　100001    3   udp    937  rstatd

　　100001    2   udp    937  rstatd

　　100001    1   udp    937  rstatd

　　那就说明rstatd服务启动了,(当然这里也可以用psax代替)

　　3)重起xinetd方法：

　　在有的系统中，通过如下命令重启：

　　# service xinetd reload

　　# /sbin/service xinetd rstart

　　在suse linux 中如下操作：

　　cd /etc/init.d/

　　./xinetd restart

　　最后，在controller中，将UNIX resources拖放到右边窗口里面，右击鼠标选择AddMeasurements，添加被监控linux的IP地址，然后选择需要监控的指标就可以了。

　　Linux的主要技术器监控与Unix监控相似