loadrunner如何监控linux，以及重点指标分析

Posted 2020-11-17 d666

监控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。
[[email protected] 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监控相似