感谢支持
我们一直在努力

Linux性能监控 – CPU、Memory、IO、Network

一、CPU
良好状态指标

CPU利用率:User Time <= 70%,System Time <= 35%,User Time + System Time <= 70%。

上下文切换:与CPU利用率相关联,如果CPU利用率状态良好,大量的上下文切换也是可以接受的。

可运行队列:每个处理器的可运行队列<=3个线程。

监控工具

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 ‘db_server_login’; sleep 1; done

  PID  NI PRI %CPU PSR COMMAND

28577  0  23  0.0  0 db_server_login

28578  0  23  0.0  3 db_server_login

28579  0  23  0.0  2 db_server_login

28581  0  23  0.0  2 db_server_login

28582  0  23  0.0  3 db_server_login

28659  0  23  0.0  0 db_server_login

……

二、Memory
良好状态指标

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

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

监控工具

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
良好状态指标

iowait % < 20%

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

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

监控工具

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

$ 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
良好状态指标

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

监控工具

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,或者没有长时间大于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 这一项数值增长了,则表明在丢包。

对于TCP
良好状态指标

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

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

监控工具

# 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 105112 76272 620 23185 6 2183206 2166093 550 6 968812

重传率 = RetransSegs / OutSegs

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

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

本文永久更新链接地址:http://www.linuxidc.com/Linux/2016-01/127431.htm

赞(0) 打赏
转载请注明出处:服务器评测 » Linux性能监控 – CPU、Memory、IO、Network
分享到: 更多 (0)

听说打赏我的人,都进福布斯排行榜啦!

支付宝扫一扫打赏

微信扫一扫打赏