Linux 性能监控

上一篇 / 下一篇  2011-06-03 16:21:29 / 个人分类:linux

  公司有个测试服务器,上面跑了几个应用和一个DBDB被这个几个应用使用。最近老是被挂掉。CPU使用率100%搞到最后大家都不能用。敲个命令都没反应。TOP命令显示的是一些Oracle session占用CPU资源太多。杯具的是在服务器上连sqlplus都进不去了,命令都没反应。只好把服务器重启了。重启之后再看了一下,是一个同事测试的SQL有问题。一条SQL占用CPU30%

      在研究这个问题的时候,也google到了一些Linux下的监控事项,整理如下。

 

 

. Linux性能监控的概述

      系统由若干子系统构成,通常修改一个子系统有可能影响到另外一个子系统,甚至会导致整个系统不稳定、崩溃。所以说优化、监测、测试通常是连在一起的,而且是一个循环而且长期的过程,通常监测的子系统有以下这些:

(1).     CPU

(2).     Memory

(3).     IO

(4).     Network

      这些子系统互相依赖,了解这些子系统的特性,监测这些子系统的性能参数以及及时发现可能会出现的瓶颈对系统优化很有帮助。

 

1.1 应用类型

      不同的系统用途也不同,要找到性能瓶颈需要知道系统跑的是什么应用、有些什么特点,比如web server对系统的要求肯定和file server不一样,所以分清不同系统的应用类型很重要,通常应用可以分为两种类型:

      1IO相关,IO相关的应用通常用来处理大量数据,需要大量内存和存储,频繁IO操作读写数据,而对CPU的要求则较少,大部分时候CPU都在等待硬盘,比如,数据库服务器、文件服务器等。

      2CPU相关CPU相关的应用需要使用大量CPU,比如高并发的web/mail服务器、图像/视频处理、科学计算等都可被视作CPU相关的应用。

 

看看实际中的例子,1个是文件服务器拷贝一个大文件时表现出来的特征:

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b  swpd  free  buff cache  si  so   bi   bo  in  cs us sy id wa st
0 4   140 1962724 335516 4852308 0   0  388 65024 1442 563 0 2 47 52 0
0 4   140 1961816 335516 4853868 0   0  768 65536 1434 522 0 1 50 48 0
0 4   140 1960788 335516 4855300 0   0  768 48640 1412 573 0 1 50 49 0
0 4   140 1958528 335516 4857280 0   0 1024 65536 1415 521 0 1 41 57 0
0 5   140 1957488 335516 4858884 0   0  768 81412 1504 609 0 2 50 49 0
 

2个是CPU做大量计算时表现出来的特征:

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b  swpd  free  buff cache  si  so   bi   bo  in  cs us sy id wa st
4 0   140 3625096 334256 3266584 0   0    0   16 1054 470 100 0 0 0 0
4 0   140 3625220 334264 3266576 0   0    0   12 1037 448 100 0 0 0 0
4 0   140 3624468 334264 3266580 0   0    0  148 1160 632 100 0 0 0 0
4 0   140 3624468 334264 3266580 0   0    0    0 1078 527 100 0 0 0 0
4 0   140 3624712 334264 3266580 0   0    0   80 1053 501 100 0 0 0 0

 

      上面两个例子最明显的差别就是id一栏,代表CPU的空闲率,拷贝文件时候id维持在50左右,CPU大量计算的时候id基本为0

 

1.2 底线

      事 先建立一个底线,如果性能监测得到的统计数据跨过这条线,我们就可以说这个系统性能差,如果数据能保持在线内我们就说性能好。建立这样底线需要知道一些理 论、额外的负载测试和系统管理员多年的经验。如果自己没有多年的经验,有一个简单划底线的办法就是:把这个底线建立在自己对系统的期望上。自己期望这个系 统有个什么样的性能,这是一个底线,如果没有达到这个要求就是性能差。

 

1.3 监测工具

工具

简单介绍

top

查看进程活动状态以及一些系统状况

vmstat

查看系统状态、硬件和系统信息等

iostat

查看CPU负载,硬盘状况

sar

综合工具,查看系统状况

mpstat

查看多处理器状况

netstat

查看网络状况

iptraf

实时网络状况监测

tcpdump

抓取网络数据包,详细分析

mpstat

查看多处理器状况

tcptrace

数据包分析工具

netperf

网络带宽工具

dstat

综合工具,综合了vmstat, iostat, ifstat, netstat等多个信息

 

Unix vmstat命令

http://blog.csdn.net/tianlesoftware/archive/2010/04/08/5464408.aspx

 

Linux Top命令详解

http://blog.csdn.net/tianlesoftware/archive/2011/02/21/6197783.aspx

 

 

. CPU

      CPU的占用主要取决于什么样的资源正在CPU上面运行,比如拷贝一个文件通常占用较少CPU,因为大部分工作是由DMADirect Memory Access)完成,只是在完成拷贝以后给一个中断让CPU知道拷贝已经完成;科学计算通常占用较多的CPU,大部分计算工作都需要在CPU上完成,内存、硬盘等子系统只做暂时的数据存储工作。要想监测和理解CPU的性能需要知道一些的操作系统的基本知识,比如:中断、进程调度、进程上下文切换、可运行队列等。   这里用个例子来简单介绍一下这些概念和他们的关系,CPU每时每刻都有工作在做(进程、线程)并且自己有一张工作清单(可运行队列),由老板(进程调度)来决定他该干什么,他需要和老板沟通以便得到老板的想法并及时调整自己的工作(上下文切换),部分工作做完以后还需要及时向老板汇报(中断),所以打工仔(CPU)除了做自己该做的工作以外,还有大量时间和精力花在沟通和汇报上。

      CPU也是一种硬件资源,和任何其他硬件设备一样也需要驱动和管理程序才能使用,我们可以把内核的进程调度看作是CPU的管理程序,用来管理和分配CPU资源,合理安排进程抢占CPU,并决定哪个进程该使用CPU、哪个进程该等待。操作系统内核里的进程调度主要用来调度两类资源:进程(或线程)和中断,进程调度给不同的资源分配了不同的优先级,优先级最高的是硬件中断,其次是内核(系统)进程,最后是用户进程。每个CPU都维护着一个可运行队列,用来存放那些可运行的线程。线程要么在睡眠状态(blocked正在等待IO)要么在可运行状态,如果CPU当前负载太高而新的请求不断,就会出现进程调度暂时应付不过来的情况,这个时候就不得不把线程暂时放到可运行队列里。

 

可以从以下几个方面监控CPU的信息:

1)中断;

2)上下文切换;

3)可运行队列;

4CPU利用率。

 

2.1底线

通常我们期望我们的系统能到达以下目标:

      1CPU利用率,如果CPU100利用率,那么应该到达这样一个平衡:65%-70User Time30%-35System Time0%-5Idle Time

      2)上下文切换,上下文切换应该和CPU利用率联系起来看,如果能保持上面的CPU利用率平衡,大量的上下文切换是可以接受的;

      3)可运行队列,每个可运行队列不应该有超过13个线程(每处理器),比如:双处理器系统的可运行队列里不应该超过6个线程。

 

2.2 vmstat

      vmstat是个查看系统整体性能的小工具,小巧、即使在很heavy的情况下也运行良好,并且可以用时间间隔采集得到连续的性能数据。

 

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b  swpd  free  buff cache  si  so   bi   bo  in  cs us sy id wa st
2 1   140 2787980 336304 3531996 0   0    0  128 1166 5033 3 3 70 25 0
0 1   140 2788296 336304 3531996 0   0    0    0 1194 5605 3 3 69 25 0
0 1   140 2788436 336304 3531996 0   0    0    0 1249 8036 5 4 67 25 0
0 1   140 2782688 336304 3531996 0   0    0    0 1333 7792 6 6 64 25 0
3 1   140 2779292 336304 3531992 0   0    0   28 1323 7087 4 5 67 25 0

 

参数介绍:

(1).     r,可运行队列的线程数,这些线程都是可运行状态,只不过CPU暂时不可用;

(2).     b,被blocked的进程数,正在等待IO请求;

(3).     in,被处理过的中断数

(4).     cs,系统上正在做上下文切换的数目

(5).     us,用户占用CPU的百分比

(6).     sys,内核和中断占用CPU的百分比

(7).     wa,所有可运行的线程被blocked以后都在等待IO,这时候CPU空闲的百分比

(8).     idCPU完全空闲的百分比

 

举两个现实中的例子来实际分析一下:

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b  swpd  free  buff cache  si  so   bi   bo  in  cs us sy id wa st
4 0   140 2915476 341288 3951700 0   0    0    0 1057 523 19 81 0 0 0
4 0   140 2915724 341296 3951700 0   0    0    0 1048 546 19 81 0 0 0
4 0   140 2915848 341296 3951700 0   0    0    0 1044 514 18 82 0 0 0
4 0   140 2915848 341296 3951700 0   0    0   24 1044 564 20 80 0 0 0
4 0   140 2915848 341296 3951700 0   0    0    0 1060 546 18 82 0 0 0

 

从上面的数据可以看出几点:

(1).     interruptsin)非常高,context switchcs)比较低,说明这个CPU一直在不停的请求资源;

(2).     user timeus)一直保持在80以上,而且上下文切换较低(cs),说明某个进程可能一直霸占着CPU

(3).     run queuer)刚好在4个。

 

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b  swpd  free  buff cache  si  so   bi   bo  in  cs us sy id wa st
14 0   140 2904316 341912 3952308 0   0    0  460 1106 9593 36 64 1 0 0
17 0   140 2903492 341912 3951780 0   0    0    0 1037 9614 35 65 1 0 0
20 0   140 2902016 341912 3952000 0   0    0    0 1046 9739 35 64 1 0 0
17 0   140 2903904 341912 3951888 0   0    0   76 1044 9879 37 63 0 0 0
16 0   140 2904580 341912 3952108 0   0    0    0 1055 9808 34 65 1 0 0

 

从上面的数据可以看出几点:

(1).     context switchcs)比interruptsin)要高得多,说明内核不得不来回切换进程;

(2).     进一步观察发现system timesy)很高而user timeus)很低,而且加上高频度的上下文切换(cs),说明正在运行的应用程序调用了大量的系统调用(system call);

(3).     run queuer)在14个线程以上,按照这个测试机器的硬件配置(四核),应该保持在12个以内。

 

我上午CPU 100%时的信息:

top - 11:49:08 up 50 days, 22:25, 6 users, load average: 59.79, 59.98, 60.50

Tasks: 200 total, 61 running, 139 sleeping,  0 stopped,  0 zombie

Cpu0 : 26.5%us, 73.5%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu1 : 25.0%us, 75.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Mem:  1939780k total, 1744412k used,  195368k free,   95704k buffers

Swap: 4401800k total,  662836k used, 3738964k free,  811124k cached

 

 

[root@localhost ~]# vmstat 2 10

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

 r b  swpd  free  buff cache  si  so   bi   bo  in  cs us sy id wa st

58 1 662836 195988 95428 810740   0   0    4  106   4   1 23 4 72 1 0

59 1 662836 195988 95448 810732   0   0    0  128 235 221 28 72 0 0 0

59 1 662836 195988 95448 810768   0   0    0    0 216 209 28 72 0 0 0

 

2.3 mpstat

      mpstatvmstat类似,不同的是mpstat可以输出多个处理器的数据。

 

注意:需要安装sysstat包后才有这个命令,可以使用yum安装:

      #yum install sysstat

      sysstat包含iostatmpstatsar、命令。

 

[root@localhost gmail]# export LANG=en_US
[root@localhost gmail]# mpstat -P ALL   
Linux 2.6.18-8.el5xen (localhost.localdomain)  02/21/2011
 
10:20:16 PM CPU  %user  %nice   %sys %iowait   %irq  %soft %steal  %idle   intr/s
10:20:16 PM all  11.49   0.00   2.58   1.04   0.01   0.13   0.01  84.74   314.61
10:20:16 PM   0  15.73   0.00   2.56   0.55   0.02

远程下载

TAG:

 

评分:0

我来说两句

Open Toolbar