linux性能监控 -CPU、Memory、IO、Network等指标的讲解

Love The Way You Lie 2021-11-23 05:42 587阅读 0赞

\[操作系统-linux\][linux性能监控 -CPU、Memory、IO、Network等指标的讲解][linux_ -CPU_Memory_IO_Network](转)

一、CPU

1、良好状态指标

*  CPU利用率：User Time <= 70%，System Time <= 35%，User Time + System Time <= 70%。
 *  上下文切换：与CPU利用率相关联，如果CPU利用率状态良好，大量的上下文切换也是可以接受的。
 *  可运行队列：每个处理器的可运行队列<=3个线程。

2、监控工具

*  vmstat

$ 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

重要参数：

r，run queue，可运行队列的线程数，这些线程都是可运行状态，只不过CPU暂时不可用；

b，被blocked的进程数，正在等待IO请求；

in，interrupts，被处理过的中断数

cs，context switch，系统上正在做上下文切换的数目

us，用户占用CPU的百分比

sys，内核和中断占用CPU的百分比

id，CPU完全空闲的百分比

上例可得：

sy高us低，以及高频度的上下文切换（cs），说明应用程序进行了大量的系统调用；

这台4核机器的r应该在12个以内，现在r在14个线程以上，此时CPU负荷很重。

*  查看某个进程占用的CPU资源

$  while :; do ps -eo pid,ni,pri,pcpu,psr,comm | grep 'test\_command'; sleep 1; done

PID  NI PRI %CPU PSR COMMAND

28577   0  23  0.0   0 test\_command

28578   0  23  0.0   3 test\_command

28579   0  23  0.0   2 test\_command

28581   0  23  0.0   2 test\_command

28582   0  23  0.0   3 test\_command

28659   0  23  0.0   0 test\_command

……

二、Memory

1、良好状态指标

*  swap in （si） == 0，swap out （so） == 0
 *  应用程序可用内存/系统物理内存 <= 70%

2、监控工具

*  vmstat

$ 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  3 252696   2432    268   7148 3604 2368  3608  2372  288  288  0  0 21 78  1

0  2 253484   2216    228   7104 5368 2976  5372  3036  930  519  0  0  0 100  0

0  1 259252   2616    128   6148 19784 18712 19784 18712 3821 1853  0  1  3 95  1

1  2 260008   2188    144   6824 11824 2584 12664  2584 1347 1174 14  0  0 86  0

2  1 262140   2964    128   5852 24912 17304 24952 17304 4737 2341 86 10  0  0  4

重要参数：

swpd，已使用的 SWAP 空间大小，KB 为单位；

free，可用的物理内存大小，KB 为单位；

buff，物理内存用来缓存读写操作的buffer大小，KB 为单位；

cache，物理内存用来缓存进程地址空间的 cache 大小，KB 为单位；

si，数据从 SWAP 读取到 RAM（swap in）的大小，KB 为单位；

so，数据从 RAM 写到 SWAP（swap out）的大小，KB 为单位。

上例可得：

物理可用内存 free 基本没什么显著变化，swapd逐步增加，说明最小可用的内存始终保持在 256MB(物理内存大小) \* 10％ = 2.56MB 左右，当脏页达到10％的时候就开始大量使用swap。

*  free

$ free -m

total used free shared buffers cached

Mem: 8111 7185 926 0 243 6299

\-/+ buffers/cache: 643 7468

Swap: 8189 0 8189

三、磁盘IO

1、良好状态指标

*  iowait % < 20%

提高命中率的一个简单方式就是增大文件缓存区面积，缓存区越大预存的页面就越多，命中率也越高。

Linux 内核希望能尽可能产生次缺页中断（从文件缓存区读），并且能尽可能避免主缺页中断（从硬盘读），这样随着次缺页中断的增多，文件缓存区也逐步增大，直到系统只有少量可用物理内存的时候 Linux 才开始释放一些不用的页。

2、监控工具

*  查看物理内存和文件缓存情况

$ cat /proc/meminfo

MemTotal:      8182776 kB

MemFree:       3053808 kB

Buffers:        342704 kB

Cached:        3972748 kB

这台服务器总共有 8GB 物理内存（MemTotal），3GB 左右可用内存（MemFree），343MB左右用来做磁盘缓存（Buffers），4GB左右用来做文件缓存区（Cached）。

*  sar

$ sar -d 2 3

Linux 2.6.9-42.ELsmp (webserver) 11/30/2008 \_i686\_ (8 CPU)

11:09:33 PM DEV tps rd\_sec/s wr\_sec/s avgrq-sz avgqu-sz await svctm %util

11:09:35 PM dev8-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

11:09:35 PM DEV tps rd\_sec/s wr\_sec/s avgrq-sz avgqu-sz await svctm %util

11:09:37 PM dev8-0 1.00 0.00 12.00 12.00 0.00 0.00 0.00 0.00

11:09:37 PM DEV tps rd\_sec/s wr\_sec/s avgrq-sz avgqu-sz await svctm %util

11:09:39 PM dev8-0 1.99 0.00 47.76 24.00 0.00 0.50 0.25 0.05

Average: DEV tps rd\_sec/s wr\_sec/s avgrq-sz avgqu-sz await svctm %util

Average: dev8-0 1.00 0.00 19.97 20.00 0.00 0.33 0.17 0.02

重要参数：

await表示平均每次设备I/O操作的等待时间（以毫秒为单位）。

svctm表示平均每次设备I/O操作的服务时间（以毫秒为单位）。

%util表示一秒中有百分之几的时间用于I/O操作。

如果svctm的值与await很接近，表示几乎没有I/O等待，磁盘性能很好，如果await的值远高于svctm的值，则表示I/O队列等待太长，系统上运行的应用程序将变慢。

如果%util接近100%，表示磁盘产生的I/O请求太多，I/O系统已经满负荷的在工作，该磁盘可能存在瓶颈。

四、Network IO

对于UDP

1、良好状态指标

接收、发送缓冲区不长时间有等待处理的网络包

2、监控工具

*  netstat

对于UDP服务，查看所有监听的UDP端口的网络情况

$ watch netstat -lunp

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

udp        0      0 0.0.0.0:64000           0.0.0.0:\*                           -

udp        0      0 0.0.0.0:38400           0.0.0.0:\*                           -

udp        0      0 0.0.0.0:38272           0.0.0.0:\*                           -

udp        0      0 0.0.0.0:36992           0.0.0.0:\*                           -

udp        0      0 0.0.0.0:17921           0.0.0.0:\*                           -

udp        0      0 0.0.0.0:11777           0.0.0.0:\*                           -

udp        0      0 0.0.0.0:14721           0.0.0.0:\*                           -

udp        0      0 0.0.0.0:36225           0.0.0.0:\*                           -

RecvQ、SendQ为0，或者不长时间有数值是比较正常的。

对于UDP服务，查看丢包情况（网卡收到了，但是应用层没有处理过来造成的丢包）

$ watch netstat -su

Udp:

278073881 packets received

4083356897 packets to unknown port received.

2474435364 packet receive errors

1079038030 packets sent

packet receive errors 这一项数值增长了，则表明在丢包。

[这里][Link 1]有对“packet receive errors”的稍微详细些的解释，它包含了7种错误，and通常表明是checksum错误。不过我们通常通过这个数值的变化来判断UDP服务是否丢包（第2项错误），不知道是否有其他什么方法来判断UDP的丢包？：

"packet receive errors" usually means:

1) data is truncated, error in checksum while copying

2) udp queue is full, so it needs to be dropped

3) unable to receive udp package from encapsulated socket

4) sock\_queue\_rcv\_skb() failed with -ENOMEM

5) it is a short packet

6) no space for header in udp packet when validating packet

7) xfrm6\_policy\_check() fails

many times it means the checksum is not right.

对于TCP（来自david的经验，thx~~）

1、良好状态指标

对于TCP而言，不会出现因为缓存不足而存在丢包的事，因为网络等其他原因，导致丢了包，协议层也会通过重传机制来保证丢的包到达对方。

所以，tcp而言更多的专注重传率。

2、监控工具

\# cat /proc/net/snmp | grep Tcp:

Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts

Tcp: 1 200 120000 -1 78447 413 50234 221 3 5984652 5653408 156800 0 849

重传率 = RetransSegs / OutSegs

至于这个值在多少范围内，算ok的，得看具体的业务了。

业务侧更关注的是响应时间。

转载于:https://www.cnblogs.com/insane-Mr-Li/p/11130979.html

[linux_ -CPU_Memory_IO_Network]: http://blog.csdn.net/cicada688/article/details/14451541
[Link 1]: http://www.withdevo.net/?p=18

linux性能监控 -CPU、Memory、IO、Network等指标的讲解

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 Oracle性能监控指标异常分析

相关性能监控 TP 指标

相关通过javamelody监控web应用的性能指标

相关 Redis性能指标详解与监控

相关通过javamelody监控web应用的性能指标

相关通过javamelody监控web应用的性能指标

相关 springboot-性能指标监控

相关监控ElasticSearch性能指标

相关网络性能监控指标

相关 linux性能监控 -CPU、Memory、IO、Network等指标的讲解