linux系统性能优化及瓶颈分析

一。用vmstat分析系统I/O情况

[[email protected] ~]# vmstat -n 3       (每一个3秒刷新一次)

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

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

1  0   144 186164 105252 2386848     0    0    18   166  83     2          48   21  31   0

2  0   144 189620 105252 2386848     0    0     0   177  1039 1210   34   10  56    0

0  0   144 214324 105252 2386848     0    0     0    10   1071   670    32   5    63    0

0  0   144 202212 105252 2386848     0    0     0   189   1035   558   20   3    77    0

2  0   144 158772 105252 2386848     0    0     0   203  1065 2832    70  14  15    0

IO

-bi:从块设备读入的数据总量(读磁盘)(KB/S)

-bo:写入到块设备的数据总量(写磁盘)(KB/S)

随机磁盘读写的时候。这2个值越大(如超出1M),能看到CPU在IO等待的值也会越大

二,用iostat分析I/O子系统情况

假设你的系统没有iostat,sar,mpstat等命令,安装sysstat- 7.0.2-1.el5.i386.rpm包,iostat工具将对系统的磁盘操作活动进行监视。它的特点是汇报磁盘活动统计情况。同一时候也会汇报出CPU 使用情况。同vmstat一样,iostat也有一个弱点,就是它不能对某个进程进行深入分析。仅对系统的总体情况进行分析。

iostat的语法例如以下:

程序代码

iostat [ -c | -d ] [ -k ] [ -t ] [ -V ] [ -x [ device ] ] [ interval [ count ] ]

-c为汇报CPU的使用情况;

-d为汇报磁盘的使用情况;

-k表示每秒按kilobytes字节显示数据;

-t为打印汇报的时间;

-v表示打印出版本号信息和使用方法;

-x device指定要统计的设备名称。默觉得全部的设备;

interval指每次统计间隔的时间;

count指依照这个时间间隔统计的次数。

iostat在内核2.4和内核2.6中数据来源不太一样,对于kernel 2.4, iostat 的数据的主要来源是 /proc/partitions;在2.6中,数据来源主要是/proc/diskstats和/sys/block/sd*/stat这两个文件

#cat /proc/diskstats | grep sda

8     0  sda   17945521  1547188    466667211  174042714   15853874 42776252   469241932  2406054445  0  137655809   2580960422

8    1   sda1  936           1876          6                12

8    2   sda2  19489178  466659986 58655070    469240224

8    3   sda3  1270         1441          33               264

8    4   sda4  4               8               0                 0

8    5   sda5  648           1442          0                 0

8    6   sda6  648           1442          0                 0

第1列 : 磁盘主设备号(major)

第2列 : 磁盘次设备号(minor)

第3列 : 磁盘的设备名(name)

第4列 : 读请求总数(rio)

第5列 : 合并的读请求总数(rmerge)

第6列 : 读扇区总数(rsect)

第7列 :   读数据花费的时间。单位是ms.(从__make_request到 end_that_request_last)(ruse)

第8列 :   写请求总数(wio)

第9列 :   合并的写请求总数(wmerge)

第10列 : 写扇区总数(wsect)

第11列 : 写数据花费的时间,单位是ms. (从__make_request到 end_that_request_last)(wuse)

第12列 : 如今正在进行的I/O数(running),等于I/O队列中请求数

第13列 : 系统真正花费在I/O上的时间,除去反复等待时间(aveq)

第14列 : 系统在I/O上花费的时间(use)。

#iostat -x 1

Linux 2.6.18-53.el5PAE (localhost.localdomain)  03/27/2009

avg-cpu:  %user   %nice %system %iowait  %steal   %idle

30.72    0.00    5.00    5.72    0.00   58.56

Device:   rrqm/s   wrqm/s    r/s    w/s     rsec/s   wsec/s   avgrq-sz avgqu-sz   await    svctm    %util

sda         0.79       21.81     9.15   8.08   237.99   239.29    27.69       1.32         76.31    4.07      7.02

sdb         0.69      19.13      3.26   2.99   153.08   176.92    52.85       0.43         68.80    5.96      3.72

sdc         3.47       89.30     10.95  7.30   213.30   772.94    54.04       1.32         72.43    4.18      7.63

每项数据的含义例如以下,

rrqm/s:     每秒进行 merge 的读操作数目。即 rmerge/s

wrqm/s:     每秒进行 merge 的写操作数目。即 wmerge/s

r/s:       每秒完毕的读 I/O 设备次数。

即 rio/s

w/s:       每秒完毕的写 I/O 设备次数。即 wio/s

rsec/s:     每秒读扇区数。即 rsect/s

wsec/s:     每秒写扇区数。即 wsect/s

rkB/s:     每秒读K字节数。

是 rsect/s 的一半。由于每扇区大小为512字节。

wkB/s:     每秒写K字节数。是 wsect/s 的一半。

avgrq-sz:   平均每次设备I/O操作的数据大小 (扇区)。

即 (rsect+wsect)/(rio+wio)

avgqu-sz:   平均I/O队列长度。

即 aveq/1000 (由于aveq的单位为毫秒)。

await:     平均每次设备I/O操作的等待时间 (毫秒)。即 (ruse+wuse)/(rio+wio)

svctm:     平均每次设备I/O操作的服务时间 (毫秒)。即 use/(rio+wio)

%util:     一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间

I/O队列是非空的,即use/1000 (由于use的单位为毫秒),

假设 %util 接近 100%。说明产生的I/O请求太多,I/O系统已经满负荷。该磁盘可能存在瓶颈。

svctm 一般要小于 await (由于同一时候等待的请求的等待时间被反复计算了),

svctm 的大小一般和磁盘性能有关,CPU/内存的负荷也会对其有影响,请求过多也会间接导致 svctm 的添加。

await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。假设 svctm 比較接近 await。说明 I/O 差点儿没有等待时间。假设 await 远大于 svctm,说明 I/O 队列太长,应用得到的响应时间变慢,假设响应时间超过了用户能够容许的范围。这时能够考虑更换更快的磁盘,调整内核 elevator 算法,优化应用。或者升级 CPU。

队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标。但因为 avgqu-sz 是依照单位时间的平均值,所以不能反映瞬间的 I/O 洪水。

io/s = r/s +w/s

await=(ruse+wuse)/io(每一个请求的等待时间)

await*io/s=每秒内的I/O请求总共须要等待的ms

avgqu-sz=await*(r/s+w/s)/1000(队列长度)

下面数据事实上与/proc/diskstats中除设备号与设备名外的其他数据是一一相应关系,仅仅是统计的方法略有区别而已。

#cat /sys/block/sda/stat

17949157  1547772 466744707 174070520 15855905 42781288 469298468 2406092114        2 137680700 2581025934

三。sar -b 监控I/O

#sar -b 1 10

Linux 2.6.18-53.el5PAE (localhost.localdomain)  03/29/2009

12:19:40 AM       tps      rtps       wtps      bread/s    bwrtn/s

12:19:42 AM     21.48      9.40     12.08    187.92    429.53

12:19:43 AM     14.00     14.00      0.00    840.00      0.00

12:19:44 AM     10.29      8.82      1.47    235.29    217.65

12:19:45 AM     12.87     10.89      1.98    752.48    142.57

12:19:46 AM     19.82     12.61      7.21    425.23    381.98

12:19:47 AM     19.00     19.00      0.00    512.00      0.00

12:19:49 AM      9.29      9.29      0.00    262.86      0.00

12:19:50 AM     16.00      5.00     11.00    144.00    536.00

12:19:51 AM     17.65      8.82      8.82    211.76    235.29

12:19:52 AM     41.41     29.29     12.12    614.14    363.64

Average:           17.75     12.30      5.45    397.19    231.99

-tps:每秒钟对磁盘发送transfer的总数。一个transfer就是一个I/O,多个逻辑请求组合成一个对磁盘的I/O请求。一个transfer的大小不确定。

-rtps:每秒钟的物理读的总数

-wtps:每秒钟的物理写的总数

-bread/s:每秒钟从磁盘读取的数据总数

-bwrtn/s:每秒钟写入磁盘的数据的总数

四,sar -d 1 10

Linux 2.6.18-53.el5PAE (localhost.localdomain)  03/29/2009

12:38:56 AM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util

12:38:57 AM     dev8-0     15.00    232.00      0.00     15.47      0.01             0.87      0.87      1.30

12:38:57 AM   dev8-16      6.00     80.00    320.00     66.67      0.05             8.67      8.67      5.20

12:38:57 AM   dev8-32     10.00    224.00      0.00     22.40      0.09             9.20      9.20      9.20

tps:每秒钟对磁盘发送transfer的总数。一个transfer就是一个I/O,多个逻辑请求组合成一个对磁盘的I/O请求,一个transfer的大小不确定

rd_sec/s

每秒钟读取的扇区数,每一个扇区512 bytes.

wr_sec/s

每秒钟写入的扇区数,每一个扇区512 bytes.

avgrq-sz

对磁盘请求的扇区的平均大小。

avgqu-sz

对磁盘请求的平均队列长度.

await

请求响应的平均时间(毫秒).包含在请求队列中的时间和响应消耗时间

svctm

对IO请求的服务时间.

%util

I/O请求占用的CPU时间百分比。

Linux命令----分析内存的瓶颈

为了提高磁盘存取效率, Linux做了一些精心的设计, 除了对dentry进行缓存(用于VFS,加速文件路径名到inode的转换), 还採取了两种主要Cache方式:Buffer Cache和Page Cache.前者针对磁盘块的读写,后者针对文件inode的读写.这些Cache有效缩短了I/O系统调用(比方 read,write,getdents)的时间.

内存活动基本上能够用3个数字来量化:活动虚拟内存总量,交换(swapping)率和调页(paging)率.当中第一个数字表明内存的总需求 量,后两个数字表示那些内存中有多少比例正处在使用之中.目标是降低内存活动或添加内存量,直到调页率保持在一个能够接受的水平上为止.

活动虚拟内存的总量(VM)=实际内存大小(size of real memory)(物理内存)+使用的交换空间大小(amount of swap space used)

当程序执行须要的内存大于物理内存时,UNIX系统採用了调页机制。即系统copy一些内存中的页面到磁盘上,腾出来空间供进程使用。

大多数系统能够忍受偶尔的调页,可是频繁的调页会使系统性能急剧下降。

UNIX内存管理:UNIX系统通过2种方法进行内存管理,“调页算法”,“交换技术”。

调页算法是将内存中近期不常使用的页面换到磁盘上,把常使用的页面(活动页面)保留在内存中供进程使用。

交换技术是系统将整个进程。而不是部分页面,所有换到磁盘上。

正常情况下,系统会发生一些交换过程。

当内存严重不足时。系统会频繁使用调页和交换,这添加了磁盘I/O的负载。进一步减少了系统对作业的运行速度,即系统I/O资源问题又会影响到内存资源的分配。

Unix的虚拟内存

Unix的虚拟内存是一个十分复杂的子系统。它实现了进程间代码与数据共享机制的透明性,并可以分配比系统现有物理内存很多其它的内存,某些操作系统的虚存甚至能通过提供缓存功能影响到文件系统的性能。各种风格的UNIX的虚存的实现方式差别非常大,但都离不开以下的4个概念。

1:实际内存

实际内存是指一个系统中实际存在的物理内存,称为RAM。

实际内存是存储暂时数据最快最有效的方式,因此必须尽可能地分配给应用程序。如今的RAM的形式有多种:SIMM、DIMM、Rambus、DDR等,非常多RAM都能够使用纠错机制(ECC)。

2:交换空间

交换空间是专门用于暂时存储内存的一块磁盘空间,通常在页面调度和交换进程数据时使用,通常推荐交换空间的大小应该是物理内存的二到四倍。

3:页面调度

页面调度是指从磁盘向内存数据传输。以及相反的过程,这个过程之所以被称为页面调度,是由于Unix内存被平均划分成大小相等的页面。通常页面大小为 4KB和8KB(在Solaris中能够用pagesize命令查看)。当可执行程序開始执行时,它的映象会一页一页地从磁盘中换入,与此类似。当某些内 存在一段时间内空暇,就能够把它们换出到交换空间中,这样就能够把空暇的RAM交给其它须要它的程序使用。

4:交换

页面调度通常easy和交换的概念混淆。页面调度是指把一个进程所占内存的空暇部分传输到磁盘上,而交换是指当系统中实际的内存已不够满足新的分配需求时。把整个进程传输到磁盘上。交换活动通常意味着内存不足。

[[email protected] ~]# vmstat -n 3       (每一个3秒刷新一次)

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

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

1  0   144 186164 105252 2386848    0    0     18   166  83     2          48   21  31  0

2  0   144 189620 105252 2386848    0    0      0   177  1039 1210   34   10  56   0

0  0   144 214324 105252 2386848    0    0      0    10   1071   670    32   5    63   0

0  0   144 202212 105252 2386848    0    0      0   189   1035   558   20   3    77   0

2  0   144 158772 105252 2386848    0    0      0   203  1065 2832    70  14  15   0

MEMORY

-swap:切换到交换内存上的内存(默认以KB为单位)

假设SWAP的值不为0。或者还比較大。比方超过100M了,可是SI,SO的值长期为0,这样的情况我们能够不用操心,不会影响系统性能。-free:空暇的物理内存

- buff:作为buffer cache的内存,对块设备的读写进行缓冲

-cache:作为page cache的内存,文件系统的cache

假设cache的值大的时候。说明cache处的文件数多,假设频繁訪问到的文件都能被cache处。那么磁盘的读IO bi会很小。

SWAP

-si:交换内存使用,由磁盘调入内存

-so:交换内存使用,由内存调入磁盘

内存够用的时候,这2个值都是0,假设这2个值长期大于0时,系统性能会受到影响。磁盘IO和CPU资源都会被消耗。

我发现有些朋友看到空暇内存(FREE)非常少的或接近于0时,就觉得内存不够用了,实际上不能光看这一点,Linux是抢占内存式的OS。还要结合si,so,假设free非常少,可是si,so也非常少(大多时候是0),那么不用操心,系统性能这时不会受到影响的。

Linux命令----分析CPU的瓶颈

衡量CPU性能的指标:

1,用户使用CPU的情况;

CPU执行常规用户进程

CPU执行niced process

CPU执行实时进程

2。系统使用CPU情况;

用于I/O管理:中断和驱动

用于内存管理:页面交换

用户进程管理:进程開始和上下文切换

3。WIO:用于进程等待磁盘I/O而使CPU处于空暇状态的比率。

4,CPU的空暇率,除了上面的WIO以外的空暇时间

5。CPU用于上下文交换的比率

6。nice

7,real-time

8,执行进程队列的长度

9,平均负载

Linux中经常使用的监控CPU总体性能的工具有:

? mpstat: mpstat 不但能查看全部CPU的平均信息,还能查看指定CPU的信息。

?

vmstat:仅仅能查看全部CPU的平均信息。查看cpu队列信息;

? iostat: 仅仅能查看全部CPU的平均信息。

? sar: 与mpstat 一样,不但能查看CPU的平均信息,还能查看指定CPU的信息。

? top:显示的信息同ps接近。可是top能够了解到CPU消耗。能够依据用户指定的时间来更新显示。

以下一一介绍:

一,vmstat

[[email protected] ~]#vmstat -n 3       (每一个3秒刷新一次)

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

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

10    144 186164 105252 2386848    0    0     18   166  83     2          48   21  31  0

20    144 189620 105252 2386848    0    0      0   177  1039 1210   34   10  56  0

00    144 214324 105252 2386848    0    0      0    10   1071   670    32   5    63  0

00    144 202212 105252 2386848    0    0      0   189   1035   558    20   3    77  0

20    144 158772 105252 2386848    0    0      0   203  1065 2832    70  14  15  0

红色内容标示CPU相关的參数PROC(ESSES)

--r:假设在processes中执行的序列(process r)是连续的大于在系统中的CPU的个数表示系统如今执行比較慢,有多数的进程等待CPU.

假设r的输出数大于系统中可用CPU个数的4倍的话,则系统面临着CPU短缺的问题,或者是CPU的速率过低,系统中有多数的进程在等待CPU,造成系统中进程执行过慢.

SYSTEM

--in:每秒产生的中断次数

--cs:每秒产生的上下文切换次数

上面2个值越大,会看到由内核消耗的CPU时间会越大

CPU

-us:用户进程消耗的CPU时间百分

us的值比較高时,说明用户进程消耗的CPU时间多,可是假设长期超50%的使用。那么我们就该考虑优化程序算法或者进行加速(比方PHP/PERL)

-sy:内核进程消耗的CPU时间百分比(sy的值高时,说明系统内核消耗的CPU资源多,这并非良性表现,我们应该检查原因)

-wa:IO等待消耗的CPU时间百分比

wa的值高时。说明IO等待比較严重,这可能因为磁盘大量作随机訪问造成,也有可能磁盘出现瓶颈(块操作)。

-id:CPU处于空暇状态时间百分比,假设空暇时间(cpu id)持续为0而且系统时间(cpu sy)是用户时间的两倍(cpu us) 系统则面临着CPU资源的短缺.

解决的方法:

当发生以上问题的时候请先调整应用程序对CPU的占用情况.使得应用程序能够更有效的使用CPU.同一时候能够考虑添加很多其它的CPU.  关于CPU的使用情 况还能够结合mpstat,  ps aux top  prstat ?a等等一些对应的命令来综合考虑关于详细的CPU的使用情况,和那些进程在占用大量的CPU时间.普通情况下,应用程序的问题会比較大一些.比方一些 SQL语句不合理等等都会造成这种现象.

二,sar

sar [options] [-A] [-o file] t [n]

在命令行中。n 和t 两个參数组合起来定义採样间隔和次数,t为採样间隔,是必须有

的參数,n为採样次数。是可选的,默认值是1。-o file表示将命令结果以二进制格式

存放在文件里,file 在此处不是keyword,是文件名称。options 为命令行选项,sar命令

的选项非常多,以下仅仅列出经常使用选项:

-A:全部报告的总和。

-u:CPU利用率

-v:进程、I节点、文件和锁表状态。

-d:硬盘使用报告。

-r:内存和交换空间的使用统计。

-g:串口I/O的情况。

-b:缓冲区使用情况。

-a:文件读写情况。

-c:系统调用情况。

-q:报告队列长度和系统平均负载

-R:进程的活动情况。

-y:终端设备活动情况。

-w:系统交换活动。

-x { pid | SELF | ALL }:报告指定进程ID的统计信息,SELFkeyword是sar进程本身的统计,ALLkeyword是全部系统进程的统计。

用sar进行CPU利用率的分析

#sar -u 2 10

Linux 2.6.18-53.el5PAE (localhost.localdomain)  03/28/2009

07:40:17 PM       CPU     %user     %nice   %system   %iowait    %steal     %idle

07:40:19 PM       all         12.44      0.00         6.97          1.74         0.00        78.86

07:40:21 PM       all         26.75      0.00        12.50         16.00       0.00        44.75

07:40:23 PM       all         16.96      0.00         7.98          0.00         0.00        75.06

07:40:25 PM       all         22.50      0.00         7.00          3.25         0.00        67.25

07:40:27 PM       all         7.25        0.00         2.75          2.50         0.00        87.50

07:40:29 PM       all         20.05      0.00         8.56          2.93         0.00        68.46

07:40:31 PM       all         13.97      0.00         6.23          3.49         0.00        76.31

07:40:33 PM       all         8.25        0.00         0.75          3.50         0.00        87.50

07:40:35 PM       all         13.25      0.00         5.75          4.00         0.00        77.00

07:40:37 PM       all         10.03      0.00         0.50          2.51         0.00        86.97

Average:             all         15.15      0.00         5.91          3.99         0.00        74.95

在显示内容包含:

  %user:CPU处在用户模式下的时间百分比。

%nice:CPU处在带NICE值的用户模式下的时间百分比。

  %system:CPU处在系统模式下的时间百分比。

  %iowait:CPU等待输入输出完毕时间的百分比。

%steal:管理程序维护还有一个虚拟处理器时,虚拟CPU的无意识等待时间百分比。

  %idle:CPU空暇时间百分比。

在全部的显示中,我们应主要注意%iowait和%idle,%iowait的值过高,表示硬盘存在I/O瓶颈。%idle值高。表示CPU较空 闲,假设%idle值高但系统响应慢时,有可能是CPU等待分配内存,此时应加大内存容量。

%idle值假设持续低于10,那么系统的CPU处理能力相对 较低。表明系统中最须要解决的资源是CPU。

用sar进行执行进程队列长度分析:

#sar -q 2 10

Linux 2.6.18-53.el5PAE (localhost.localdomain)  03/28/2009

07:58:14 PM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15

07:58:16 PM         0         493          0.64        0.56        0.49

07:58:18 PM         1         491          0.64        0.56        0.49

07:58:20 PM         1         488          0.59        0.55        0.49

07:58:22 PM         0         487          0.59        0.55        0.49

07:58:24 PM         0         485          0.59        0.55        0.49

07:58:26 PM         1         483          0.78        0.59        0.50

07:58:28 PM         0         481          0.78        0.59        0.50

07:58:30 PM         1         480          0.72        0.58        0.50

07:58:32 PM         0         477          0.72        0.58        0.50

07:58:34 PM         0         474          0.72        0.58        0.50

Average:               0         484          0.68        0.57        0.49

runq-sz 准备执行的进程执行队列。

plist-sz  进程队列里的进程和线程的数量

ldavg-1  前一分钟的系统平均负载(load average)

ldavg-5  前五分钟的系统平均负载(load average)

ldavg-15  前15分钟的系统平均负载(load average)

顺便说一下load avarage的含义

load average能够理解为[size=+0]每秒钟CPU等待执行的进程个数.

在Linux系统中。sar -q、uptime、w、top等命令都会有系统平均负载load average的输出,那么什么是系统平均负载呢?

  系统平均负载被定义为在特定时间间隔内执行队列中的平均任务数。假设一个进程满足下面条件则其就会位于执行队列中:

  - 它没有在等待I/O操作的结果

  - 它没有主动进入等待状态(也就是没有调用‘wait‘)

  - 没有被停止(比如:等待终止)

  比如:

# uptime

  20:55:40 up 24 days,  3:06,  1 user,  load average: 8.13, 5.90, 4.94

  命令输出的最后内容表示在过去的1、5、15分钟内执行队列中的平均进程数量。

  一般来说仅仅要每一个CPU的当前活动进程数不大于3那么系统的性能就是良好的,如果每一个CPU的任务数大于5,那么就表示这台机器的性能有严重问题。对 于上面的样例来说。如果系统有两个CPU,那么其每一个CPU的当前任务数为:8.13/2=4.065。这表示该系统的性能是能够接受的。

三。iostat

#iostat -c 2 10

Linux 2.6.18-53.el5PAE (localhost.localdomain)  03/28/2009

avg-cpu:  %user   %nice %system %iowait  %steal   %idle

30.10    0.00          4.89         5.63    0.00   59.38

avg-cpu:  %user   %nice %system %iowait  %steal   %idle

8.46       0.00          1.74         0.25    0.00   89.55

avg-cpu:  %user   %nice %system %iowait  %steal   %idle

22.06     0.00          11.28       1.25    0.00   65.41

四,mpstat

mpstat是 Multiprocessor Statistics的缩写。是实时系统监控工具。

其报告与CPU的一些统计信息,这些信息存放在/proc/stat文件里。在多CPUs系统里。其不 但能查看全部CPU的平均状况信息。并且可以查看特定CPU的信息。以下仅仅介绍 mpstat与CPU相关的參数。mpstat的语法例如以下:

mpstat [-P {|ALL}] [internal [count]]

參数的含义例如以下:

參数 解释

-P {|ALL} 表示监控哪个CPU。 cpu在[0,cpu个数-1]中取值

internal 相邻的两次採样的间隔时间

count 採样的次数,count仅仅能和delay一起使用

当没有參数时,mpstat则显示系统启动以后全部信息的平均值。有interval时。第一行的信息自系统启动以来的平均信息。从第二行開始。输出为前一个interval时间段的平均信息。与CPU有关的输出的含义例如以下:

參数 解释 从/proc/stat获得数据

CPU 处理器ID

user 在internal时间段里,用户态的CPU时间(%) ,不包括 nice值为负 进程 ?

usr/?total*100

nice 在internal时间段里,nice值为负进程的CPU时间(%) ?nice/?

total*100

system 在internal时间段里,核心时间(%) ?system/?total*100

iowait 在internal时间段里,硬盘IO等待时间(%) ?iowait/?total*100

irq 在internal时间段里,软中断时间(%) ?irq/?total*100

soft 在internal时间段里,软中断时间(%) ?softirq/?

total*100

idle 在internal时间段里。CPU除去等待磁盘IO操作外的由于不论什么原因而空暇的时间闲置时间 (%) ?idle/?total*100

intr/s 在internal时间段里,每秒CPU接收的中断的次数 ?intr/?

total*100

CPU总的工作时间=total_cur=user+system+nice+idle+iowait+irq+softirq

total_pre=pre_user+ pre_system+ pre_nice+ pre_idle+ pre_iowait+ pre_irq+ pre_softirq

?user=user_cur ? user_pre

?total=total_cur-total_pre

当中_cur 表示当前值,_pre表示interval时间前的值。上表中的全部值可取到两位小数点。#mpstat -P ALL 2 10

Linux 2.6.18-53.el5PAE (localhost.localdomain)  03/28/2009

10:07:57 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s

10:07:59 PM  all   20.75    0.00   10.50    1.50    0.25    0.25    0.00   66.75   1294.50

10:07:59 PM    0   16.00    0.00    9.00    1.50    0.00    0.00    0.00   73.50   1000.50

10:07:59 PM    1   25.76    0.00   12.12    1.52    0.00    0.51    0.00   60.10    294.00

时间: 2024-10-05 04:58:50

linux系统性能优化及瓶颈分析的相关文章

Linux转发性能评估与优化(转发瓶颈分析与解决方案)

线速问题 很多人对这个线速概念存在误解.认为所谓线速能力就是路由器/交换机就像一根网线一样.而这,是不可能的.应该考虑到的一个概念就是延迟.数据包进入路由器或者交换机,存在一个核心延迟操作,这就是选路,对于路由器而言,就是路由查找,对于交换机而言,就是查询MAC/端口映射表,这个延迟是无法避开的,这个操作需要大量的计算机资源,所以不管是路由器还是交换机,数据包在内部是不可能像在线缆上那样近光速传输的.类比一下你经过十字街头的时候,是不是要左顾右盼呢? 那么,设备的线速能力怎么衡量呢?如果一个数据

Linux转发性能评估与优化-转发瓶颈分析与解决方式(补遗)

补遗 关于网络接收的软中断负载均衡,已经有了成熟的方案,可是该方案并不特别适合数据包转发,它对server的小包处理非常好.这就是RPS.我针对RPS做了一个patch.提升了其转发效率. 下面是我转载的我自己的原文. 线速问题 非常多人对这个线速概念存在误解.觉得所谓线速能力就是路由器/交换机就像一根网线一样.而这.是不可能的.应该考虑到的一个概念就是延迟. 数据包进入路由器或者交换机.存在一个核心延迟操作,这就是选路,对于路由器而言.就是路由查找,对于交换机而言,就是查询MAC/port映射

Linux转发性能评估与优化-转发瓶颈分析与解决方案(补遗)

补遗 关于网络接收的软中断负载均衡,已经有了成熟的方案,但是该方案并不特别适合数据包转发,它对服务器的小包处理非常好,这就是RPS.我针对RPS做了一个patch,提升了其转发效率. 下面是我转载的我自己的原文. 线速问题 很多人对这个线速概念存在误解.认为所谓线速能力就是路由器/交换机就像一根网线一样.而这,是不可能的.应该考虑到的一个概念就是延迟.数据包进入路由器或者交换机,存在一个核心延迟操作,这就是选路,对于路由器而言,就是路由查找,对于交换机而言,就是查询MAC/端口映射表,这个延迟是

linux系统瓶颈分析(精)

linux系统瓶颈分析(精) (2013-09-17 14:22:00)   分类: linux服务器瓶颈分析 1.0 性能监控介绍 性能优化就是找到系统处理中的瓶颈以及去除这些的过程,多数管理员相信看一些相关的"cook book"就 可以实现性能优化,通常通过对内核的一些配置是可以简单的解决问题,但并不适合每个环境,性能优化其实 是对OS 各子系统达到一种平衡的定义,这些子系统包括了: CPU Memory IO Network 这些子系统之间关系是相互彼此依赖的,任何一个高负载都

MySQL瓶颈分析与优化

简介 通过sysbench的oltp_read_write测试来模拟业务压力.以此来给指定的硬件环境配置一份比较合理的MySQL配置文件. 环境介绍 硬件配置 软件环境 优化层级与指导思想 优化层级 MySQL数据库优化可以在多个不同的层级进行,常见的有: SQL优化 参数优化 架构优化 本文重点关注:参数优化 指导思想 日志先行 -- 一个事务能否成功提交的关键是日志是否成功落盘,与数据没有太大的关系:也就是说对写的优化可以表述为各方面的资源向写操作倾斜. 瓶颈分析 -- 通过show glo

bcc 基于bpf 分析linux 系统性能的强大工具包

bcc 是一个基于bpf 的强大linux io,网络监控分析工具集(当然也可以分析java,ruby,python...) 一张工具图 说明 bcc 好多工具是需要kernel 4.1 的,但是大部分还是可以使用的,功能很强大,如果感觉bcc太过复杂,perf-tools 也是一个不错的选择 参考资料 https://github.com/iovisor/bcc 原文地址:https://www.cnblogs.com/rongfengliang/p/12044201.html

linux性能优化cpu 磁盘IO MEM

系统优化是一项复杂.繁琐.长期的工作,优化前需要监测.采集.测试.评估,优化后也需要测试.采集.评估.监测,而且是一个长期和持续的过程,不 是说现在优化了,测试了,以后就可以一劳永逸了,也不是说书本上的优化就适合眼下正在运行的系统,不同的系统.不同的硬件.不同的应用优化的重点也不同. 优化的方法也不同.优化的参数也不同.性能监测是系统优化过程中重要的一环,如果没有监测.不清楚性能瓶颈在哪里,怎么优化呢?所以找到性能 瓶颈是性能监测的目的,也是系统优化的关键.系统由若干子系统构成,通常修改一个子系

性能测试—瓶颈分析方法

1.内存分析方法 内存分析用于判断系统有无内存瓶颈,是否需要通过增加内存等手段提高系统性能表现. 内存分析需要使用的计数器:Memory类别和Physical Disk类别的计数器.内存分析的主要方法和步骤: (1)首先查看Memory\Available Mbytes指标 如果该指标的数据比较小,系统可能出现了内存方面的问题,需要继续下面步骤进一步分析. 注: 在UNIX/LINUX中,对应指标是FREE(KB) (2)注意Pages/sec.Pages Read/sec和Page Fault

Android/Linux 系统性能调优

关于性能优化这是一个比较大的话题,今天,想从一些技术细节上谈谈性能优化,主要是一些代码级别的技术和方法.本文的东西是我的一些经验和知识,并不一定全对,希望大家指正和补充. 在开始这篇文章之前,大家可以移步去看一下酷壳以前发表的<代码优化概要>,这篇文章基本上告诉你--要进行优化,先得找到性能瓶颈! 但是在讲如何定位系统性能瓶劲之前,请让我讲一下系统性能的定义和测试,因为没有这两件事,后面的定位和优化无从谈起. 一.系统性能定义 让我们先来说说如何什么是系统性能.这个定义非常关键,如果我们不清楚