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

指标

工具

cpu

usr<=70%, sys<=35%, usr+sys<=70%

top

memory

si == so == 0 可用空间>=30%

vmstat 1;free; /proc/meminfo

io

iowait% < 20%

iostat -x;

network

udp:缓冲区不挤压, 无丢包 tcp:重传率

netstat -lunp; netstat -su; /proc/net/snmp

一、CPU

1.良好状态指标

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

2.监控工具

  • top 最常用 略
  • vmstat
$ vmstat 1 (1 表示 1s 输出一次)
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

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
 1  0 2085940 402932 245856 8312440    1    1    15   172    0    0  7  5 88  0  0
 1  0 2085940 400196 245856 8315148    0    0   532     0 4828 9087 30  6 63  1  0
 2  0 2085940 397716 245868 8317908    0    0   464   552 4311 8427 29  6 65  0  0
 2  0 2085940 393144 245876 8322484    0    0   584  2556 4620 9054 30  5 65  0  0
 2  0 2085940 389368 245876 8325408    0    0   592     0 4460 8779 30  5 65  0  0

重要参数:

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。

$ 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
^C
  • free
$ free
             total       used       free     shared    buffers     cached
Mem:      15728640   15600636     128004          0          0   13439080
-/+ buffers/cache:    2161556   13567084
Swap:      2104508     276276    1828232

单位KB。可以用 -m 选项要求输出单位为MB。

我们使用total1、used1、free1、used2、free2 等名称来代表上面统计数据的各值,1、2 分别代表第一行和第二行的数据。

total1:表示物理内存总量。 used1:表示总计分配给缓存(包含buffers 与cache )使用的数量,但其中可能部分缓存并未实际使用。 free1:未被分配的内存。 shared1:共享内存,一般系统不会用到,这里也不讨论。 buffers1:系统分配但未被使用的buffers 数量。 cached1:系统分配但未被使用的cache 数量。buffer 与cache 的区别见后面。 used2:实际使用的buffers 与cache 总量,也是实际使用的内存总量。 free2:未被使用的buffers 与cache 和未被分配的内存之和,这就是系统当前实际可用内存。

cache 和 buffer的区别:

Cache:高速缓存,是位于CPU与主内存间的一种容量较小但速度很高的存储器。

由于CPU的速度远高于主内存,CPU直接从内存中存取数据要等待一定时间周期,Cache中保存着CPU刚用过或循环使用的一部分数据,当CPU再次使用该部分数据时可从Cache中直接调用,这样就减少了CPU的等待时间,提高了系统的效率。

Cache又分为一级Cache(L1 Cache)和二级Cache(L2 Cache),L1 Cache集成在CPU内部,L2 Cache早期一般是焊在主板上,现在也都集成在CPU内部,常见的容量有256KB或512KB L2 Cache。

Buffer:缓冲区,一个用于存储速度不同步的设备或优先级不同的设备之间传输数据的区域。 通过缓冲区,可以使进程之间的相互等待变少,从而使从速度慢的设备读入数据时,速度快的设备的操作进程不发生间断。

Free中的buffer和cache:(它们都是占用内存)

buffer : 作为buffer cache的内存,是块设备的读写缓冲区

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

如果 cache 的值很大,说明cache住的文件数很多。如果频繁访问到的文件都能被cache住,那么磁盘的读IO 必会非常小。

  • $ cat /proc/meminfoMemTotal: 15728640 kB MemFree: 116196 kB Buffers: 0 kB Cached: 13448268 kB ……

这台服务器总共有 8GB 物理内存(MemTotal),3GB 左右可用内存(MemFree),343MB左右用来做磁盘缓存(Buffers),4GB左右用来做文件缓存区(Cached)。 用free命令也可以查到这几个值,注意单位是kB。

三、磁盘IO

1.良好状态指标

  • iowait % < 20% 提高命中率的一个简单方式就是增大文件缓存区面积,缓存区越大预存的页面就越多,命中率也越高。 Linux 内核希望能尽可能产生次缺页中断(从文件缓存区读),并且能尽可能避免主缺页中断(从硬盘读),这样随着次缺页中断的增多,文件缓存区也逐步增大,直到系统只有少量可用物理内存的时候 Linux 才开始释放一些不用的页。

2.监控工具

  • sar
$ sar -d 2 3 (2秒一次 共3次)
Linux 3.10.83-1-tlinux2-0021.tl1 (xgame_9_zone1)        06/22/17        _x86_64_        (48 CPU)

16:50:05          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
16:50:07       dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

16:50:07          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
16:50:09       dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

16:50:09          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
16:50:11       dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

Average:          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
Average:       dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

重要参数:

await表示平均每次设备I/O操作的等待时间(以毫秒为单位)。 svctm表示平均每次设备I/O操作的服务时间(以毫秒为单位)。 %util表示一秒中有百分之几的时间用于I/O操作。

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

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

  • $ iostat -x(选项 -x 用于显示和io相关的扩展数据)
Linux 3.10.83-1-tlinux2-0021.tl1 (xgame_9_zone1)        06/22/17        _x86_64_        (48 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.46    0.00    2.75    0.01    0.00   94.78

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00    0.00    0.00     0.00     0.00   153.95     0.00    1.02   0.47   0.00

查看哪个进程占IO:iotop,效果和top看cpu一样。 查看某个进程打开的文件:/proc/${pid}/fd

四、Network IO

对于UDP

1.良好状态指标

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

2.监控工具

  • netstat

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

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

对于TCP(来自davidshan单卫的经验,thx~)

1.良好状态指标

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

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

2、监控工具

通过snmp可以查看各层网络协议的收发包的情况

$ 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的,得看具体的业务了。

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

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

刘爽的专栏

1 篇文章1 人订阅

我来说两句

0 条评论
登录 后参与评论

相关文章

扫码关注云+社区