如何通过sar快速定位制约系统性能的瓶颈

简介:

在系统运行效率慢之前和运行效率慢的时候分别执行sar操作,
对比二者的结果可以比较快的判断出问题所在

第1步:
# sar 1 5
09:35:13    %usr    %sys    %wio   %idle (-u)
09:35:14      17       0       0      83
09:35:15       5       0       0      95
09:35:16       5       0       0      95
09:35:17       5       0       0      95
09:35:18       5       1       0      94

Average        7       0       0      92
对比系统变慢之前和慢之间分别执行上述命令的结果可以初步定位系统主要的瓶颈

如果%usr的平均值高,表示系统等待用户程序的比例高
(比如排序,数据处理,数据计算等)
罪魁祸首:高峰期不必要的程序运行,CPU速度慢或数量不足,
效率低下的用户程序或守护处理进程以及错误的进程优先级nice

如果%sys高,表示系统等待设备驱动系统调用的比例高
罪魁祸首:效率低下的设备驱动程序,硬件故障导致的假中断,
CPU速度慢或数量不足

如果%usr和%sys都高,表示系统等待用户或内核产生的系统调用比例高
罪魁祸首:CPU速度慢或数量不足

如果%wio高,表示系统等待硬盘io存取数据的比例高
罪魁祸首:硬盘缓存不足(NBUF/NHBUF配置不足),硬盘慢,
内存不足,运行程序有内存泄漏或占用过多内存

第2步:
一 如果%usr高:
1)检查占用CPU的进程
# ps -el | more
  F S    UID   PID  PPID  C PRI NI     ADDR   SZ  TTY       TIME CMD
71 S      0     0     0  0  95 20 fb117000    0    ?   00:00:01 sched
20 S      0     1     0  0  66 20 fb117158  148    ?   00:00:00 init
...
20 S      0   347     1  0  76 24 fb119db0  312    ?   00:00:00 snmpd
20 S     17   349     1  1  66 20 fb119f08  156    ?   01:05:53 deliver
20 S      0   413   410  0  75 20 fb11a060  128    ?   00:00:00 lockd
检查C和TIME列的值,如果哪行TIME(单位是分:秒:百分之一秒)异常的高,并且C是>0的数字,
那么这个CMD显示的进程程序就是太耗费资源的元凶,
上面所是的例子deliver表示累计占了1分钟CPU,还算正常,假如是1000:05:53那么它就是问题所在了

也可用who命令检查,比如
# w
   4:41pm  up  5:04,  3 users,  load average: 0.00 0.00 0.00
User     tty            login@   idle    JCPU    PCPU  what
root     tty01         11:51am          21:38          bash
root     tty03          4:31pm      9                  -sh
root     ttyp1          1:55pm                         w

# who -u | sort -k 6 -r
root       tty03        Jul  6 16:31  0:09   1774
root       ttyp1        Jul  6 13:55  0:01   3902
root       tty01        Jul  6 11:51   .     1773

2) 检查系统调用的情况
# sar -c 1 5
SCO_SV tuvok 3.2v5.0.5 i80386    06/21/2001

09:55:08 scall/s sread/s swrit/s  fork/s  exec/s  rchar/s  wchar/s (-c)
09:55:09    1216      67      12    0.99    0.99   178441     3988
09:55:10     147      31       6    0.00    0.00   168723     8421
09:55:11      74      27       4    0.00    0.00   163644     3342
09:55:12     245      37       6    0.00    0.00   171821     8928
09:55:13     151      29       4    0.00    0.00   163770     3468

Average      367      38       6    0.20    0.20   169280     5629
对比系统变慢之前和慢之间分别执行上述命令的结果,
如果系统变慢之后scall/s列的值增大很多,表示
    .程序突然被频繁使用
    .系统运行的程序太多了,可用ps命令确认.
如果系统变慢之后fork/s,exec/s或sread/s,swrit/s异常的高,
检查fork过多,读写操作频繁的程序,优化代码降低资源占用

二 如果%sys高
如果是多CPU系统且系统有SMP支持,执行下列命令查看是否有设备在发送成千上万的中断
OpenServer5执行: #sar -j 1 5
UnixWare7/OpenUnix8执行: #sar -P ALL 1 5
检查访问磁带机,第3方smart boards以及非硬盘设备的设备的程序

三 如果%usr和%sys都高
1) 检查系统队列
# sar -q 1 5

SCO_SV lunasco 3.2v5.0.4 Pentium    06/21/2001

10:46:29 runq-sz %runocc swpq-sz %swpocc (-q)
10:46:30     3.0     100
10:46:31
10:46:32     1.0     100
10:46:33     1.0     100
10:46:34     1.0     100

Average      1.5     100
其中time平均值应该<3,如果持续高于3那么表示CPU能力不足,如果可能超频或增加CPU

四 如果%wio高
1)找出占用资源过多的进程
# ps -el | more
  F S    UID   PID  PPID  C PRI NI     ADDR   SZ  TTY        TIME CMD
71 S      0     0     0  0  95 20 fb117000    0    ?    00:00:01 sched
20 S      0     1     0  0  66 20 fb117158  148    ?    00:00:00 init
71 S      0     2     0  0  95 20 fb1172b0    0    ?    00:00:00 vhand
71 S      0     3     0  0  95 20 fb117408    0    ?    00:00:16 bdflush
71 S      0     4     0  0  95 20 fb117560    0    ?    00:00:00 kmdaemon
71 S      0     5     1  0  95 20 fb1176b8    0    ?    00:00:18 htepi_daemon
...
20 S      0   252     1  0  76 20 fb118830  152    ?    00:00:00 cron
20 S      0   354     1  0  76 24 fb118988 233504    ?    00:00:03 report
20 S      0   496     1  0  76 24 fb118ae0  200    ?    00:00:00 calserver
检查那些SZ值高的程序,看看是否占用内存过多或没有及时释放内存,
上面所列的report程序就占太多的内存资源

2)检查可用内存大小
# sar -r 1 5

SCO_SV tuvok 3.2v5.0.5 i80386    06/21/2001

10:34:13   freemem   freeswp availrmem availsmem (-r)
10:34:14      8262    389120     28765     56421
10:34:15      8262    389120     28765     56421
10:34:16      8262    389120     28765     56421
10:34:17      8262    389120     28765     56421
10:34:18      8262    389120     28765     56421

Average       8262    389120     28765     56421
如果freemem(单位4K页)<500并且freeswp变化较大,表明内存不足需要增加内存
注意: OpenServer5的sar -r列出的是硬盘上所有交换区容量的和,
Unixware7/OpenUnix8的sar -r列出的是内存条RAM容量加上交换区的容量值

3) 检查硬盘IO情况
# sar -b 1 5
SCO_SV tuvok 3.2v5.0.5 i80386    06/21/2001
10:37:17 bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s (-b)
10:37:18       0       0       0       0       0       0       0       0
10:37:19       0       0       0       0       0       0       0       0
10:37:20       0      60     100       0       1     100       0       0
10:37:21       0      -1     100       0       0       0       0       0
10:37:22       0      56     100       0       1     100       0       0

Average        0      24     100       0       0     100       0       0
如果 %rcache 的值持续<85 或 %wcache的值<80,那么表明系统硬盘缓存不足
把内核参数NBUF调大50%,同时适当加大NHBUF

Unixware7/OpenUnix8下还需要调整下列内核参数:
"FDFLUSHR": 检查是否需要写缓存和文件页到硬盘的时间间隔(秒),默认为1秒
"NAUTOUP", 文件系统update的时间间隔(秒) 默认是60秒
也可用sar -d检查磁盘IO情况
# sar -d
UnixWare omega 5 7.1.3 i386    02/09/05
00:00:00 device         MB       %busy   avque   r+w/s  blks/s  avwait  avserv
10:40:01 c0b0t0d0s1     12867       90    23.7       8      83  2556.6   112.8
10:40:01 c0b0t0d0s10    50           0     1.0       0       0     0.0   790.0
10:40:01 c0b0t0d0       17359       90    23.7       8      83  2556.4   112.8
10:40:01 c0b0t1d0s12    65458        1     1.6       2      21     4.1     6.9
10:40:01 c0b0t1d0       69459        1     1.6       2      21     4.1     6.9
10:40:01 c0b0t2d0s1     138918       2     3.2       4      86    13.3     6.1
10:40:01 c0b0t2d0       138919       2     3.2       4      86    13.3     6.1
对于%busy平均值超过50的硬盘可断定此硬盘目前是影响系统IO性能的瓶颈,
对于RAID系统,检查逻辑盘状态可通过厂商提供的工具,
比如HP CISS SMART ARRAY 可运行/usr/bin/compaq/bin/diags/ciss_menu来检查

如果硬盘指标看起来尚可接受,但是系统的确耗费了大量的时间在IO等待上,
那么应该需要加内存,并确认是把内核参数NBUF设置到运行所需的实际内存大小

如果内存和硬盘IO都没有问题,那么你可能需要使用RAID以平衡硬盘负载,
或者换一个更快的磁盘适配器(disk adapter)

最后补充说明一下:
首先你要确认已经安装了最新的系统补丁,
包括SCSI卡,网卡最新的驱动在内所有sco提供的补丁均可从
ftp.sco.com下载

除了sar之外还有一些非常有用的第3方工具可以帮助你检测系统的运行情况


本文转自守住每一天51CTO博客,原文链接:http://blog.51cto.com/liuyu/81115,如需转载请自行联系原作者

相关文章
|
4月前
|
设计模式 监控 安全
如何定位当生产环境CPU飙升的时候的问题
在当今的信息化时代,计算机系统在各行各业都发挥着重要的作用。然而,当生产环境中的CPU飙升时,系统性能会受到影响,甚至导致整个系统瘫痪。这不仅会对企业造成经济损失,还会对用户体验造成严重影响。因此,如何定位并解决生产环境中CPU飙升的问题,已成为众多企业和开发人员亟待解决的问题之一。本文旨在探讨如何定位生产环境中CPU飙升的问题,并提供相应的解决方案。通过了解CPU飙升的原因、定位方法以及解决方案,企业和开发人员可以更好地应对生产环境中出现的CPU飙升问题,提高系统性能和用户体验。
76 1
|
3月前
|
安全 调度
影响RTOS实时性的因素
影响RTOS实时性的因素
|
9月前
|
Java
精准定位Java应用CPU负载过高问题
trace指令能追踪调用链路,而Springmvc应用都是借助于:javax.servlet.Servlet * 执行的 watch指令能够实时监测指定方法的:返回值,抛出异常,入参,同时支持OGNL操作
80 1
|
9月前
|
Web App开发 Java Linux
【性能优化】使用Perfetto定位应用启动性能的瓶颈
本篇文章将会结合我个人对Perfetto的实际使用经历,讲解车载应用的启动时间是如何测量得到的,测量出启动时间后,我们又该如何找出其中的性能瓶颈。
811 1
【性能优化】使用Perfetto定位应用启动性能的瓶颈
|
监控 NoSQL Redis
记一次线上CPU过高的问题以及处理方案
本人所在的项目是一个支付项目,有个场景就是当用户下单之后,需要及时的知道订单的支付状态,有的渠道回调比较慢,故在用户下单之后将订单信息放入redis,然后不断的去轮询调用渠道方订单查询接口。
149 0
记一次线上CPU过高的问题以及处理方案
|
Linux 应用服务中间件
尝试找出linux服务器性能瓶颈--影响平均负载的几类因素
linux系统的多任务处理能力受到广泛偏好,但性能瓶颈的指标非常繁多。我们今天来看一下如何查看系统性能负载的瓶颈。我们用性能测试的软件模拟下环境。来探究下如何发现真正的性能瓶颈
1381 0
|
Java
【JVM调优系列】----CPU过高的分析与解决方案
问题描述          服务器是8核32G的,也就是说同时可用的共有8个CPU,一个CPU可以使用高达100%,8个CPU的话可以高达800%。
2085 0