linux 采集io cpu ram,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------

rbswpd   free   buff  cache   si   so    bi    boincs us sy idwa st

140140 2904316 341912 3952308000460 1106 9593 36 64100

170140 2903492 341912 39517800000 1037 9614 35 65100

200140 2902016 341912 39520000000 1046 9739 35 64100

170140 2903904 341912 395188800076 1044 9879 37 63000

160140 2904580 341912 39521080000 1055 9808 34 65100

重要参数：

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

PIDNI PRI %CPU PSR COMMAND

28577   0  23  0.0   0test_command

28578   0  23  0.0   3test_command

28579   0  23  0.0   2test_command

28581   0  23  0.0   2test_command

28582   0  23  0.0   3test_command

28659   0  23  0.0   0test_command

……

二、Memory

1、良好状态指标

swap in (si)== 0，swap out (so)== 0

应用程序可用内存/系统物理内存<= 70%

2、监控工具

vmstat

$ vmstat 1

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

rbswpdfreebuff  cachesi   sobi    bo   in   cs us sy id wa st

03 25269624322687148 3604 23683608237228828800 21 781

02 25348422162287104 5368 297653723036930519000 1000

01 25925226161286148 19784 18712 19784 18712 3821 1853013 951

12 26000821881446824 11824 2584 126642584 1347 1174 1400 860

21 26214029641285852 24912 17304 24952 17304 4737 2341 86 10004

重要参数：

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 这一项数值增长了，则表明在丢包。

这里有对“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的，得看具体的业务了。

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