UDN-企业互联网技术人气社区

板块导航

浏览  : 996
回复  : 1

[干货] Linux性能监控——CPU,Memory,IO,Network

[复制链接]
舞操的头像 楼主
  一.CPU

  1.良好状态指标

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

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

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

  2.监控工具

  vmstat

  1.   $ vmstat 1

  2.   procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

  3.   r b swpd free buff cache si so bi bo in cs us sy id wa st

  4.   14 0 140 2904316 341912 3952308 0 0 0 460 1106 9593 36 64 1 0 0

  5.   17 0 140 2903492 341912 3951780 0 0 0 0 1037 9614 35 65 1 0 0

  6.   20 0 140 2902016 341912 3952000 0 0 0 0 1046 9739 35 64 1 0 0

  7.   17 0 140 2903904 341912 3951888 0 0 0 76 1044 9879 37 63 0 0 0

  8.   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资源

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

  2.   PID NI PRI %CPU PSR COMMAND

  3.   28577 0 23 0.0 0 db_server_login

  4.   28578 0 23 0.0 3 db_server_login

  5.   28579 0 23 0.0 2 db_server_login

  6.   28581 0 23 0.0 2 db_server_login

  7.   28582 0 23 0.0 3 db_server_login

  8.   28659 0 23 0.0 0 db_server_login

  9.   ……
复制代码


  二.Memory

  1.良好状态指标

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

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

  2.监控工具

  vmstat

  1.   $ vmstat 1

  2.   procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

  3.   r b swpd free buff cache si so bi bo in cs us sy id wa st

  4.   0 3 252696 2432 268 7148 3604 2368 3608 2372 288 288 0 0 21 78 1

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

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

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

  8.   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

  1.   $ free -m

  2.   total used free shared buffers cached

  3.   Mem: 8111 7185 926 0 243 6299

  4.   -/+ buffers/cache: 643 7468

  5.   Swap: 8189 0 8189
复制代码


  三.磁盘IO

  1.良好状态指标

  iowait % < 20%

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

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

  2.监控工具

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

  1.   $ cat /proc/meminfo

  2.   MemTotal: 8182776 kB

  3.   MemFree: 3053808 kB

  4.   Buffers: 342704 kB

  5.   Cached: 3972748 kB
复制代码


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

  sar

 
  1.  $ sar -d 2 3

  2.   Linux 2.6.9-42.ELsmp (webserver) 11/30/2008 _i686_ (8 CPU)

  3.   11:09:33 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util

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

  5.   11:09:35 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util

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

  7.   11:09:37 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util

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

  9.   Average: DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util

  10.   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端口的网络情况

  1.   $ watch netstat -lunp

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

  3.   udp 0 0 0.0.0.0:64000 0.0.0.0:* -

  4.   udp 0 0 0.0.0.0:38400 0.0.0.0:* -

  5.   udp 0 0 0.0.0.0:38272 0.0.0.0:* -

  6.   udp 0 0 0.0.0.0:36992 0.0.0.0:* -

  7.   udp 0 0 0.0.0.0:17921 0.0.0.0:* -

  8.   udp 0 0 0.0.0.0:11777 0.0.0.0:* -

  9.   udp 0 0 0.0.0.0:14721 0.0.0.0:* -

  10.   udp 0 0 0.0.0.0:36225 0.0.0.0:* -
复制代码


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

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

  1.   $ watch netstat -su

  2.   Udp:

  3.   278073881 packets received

  4.   4083356897 packets to unknown port received.

  5.   2474435364 packet receive errors

  6.   1079038030 packets sent
复制代码


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

  这里有对packet receive errors的稍微详细些的解释,它包含了7种错误,and通常表明是checksum错误。不过我们通常通过这个数值的变化来判断UDP服务是否丢包(第2项错误),不知道是否有其他什么方法来判断UDP的丢包?:

  1.   "packet receive errors" usually means:

  2.   1) data is truncated, error in checksum while copying

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

  4.   3) unable to receive udp package from encapsulated socket

  5.   4) sock_queue_rcv_skb() failed with -ENOMEM

  6.   5) it is a short packet

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

  8.   7) xfrm6_policy_check() fails

  9.   many times it means the checksum is not right.
复制代码


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

  1.良好状态指标

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

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

  2、监控工具

  1.   # cat /proc/net/snmp | grep Tcp:

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

  3.   Tcp: 1 200 120000 -1 78447 413 50234 221 3 5984652 5653408 156800 0 849
复制代码


  重传率 = RetransSegs / OutSegs

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

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

原文作者:佚名  来源:开发者头条

相关帖子

发表于 2017-1-5 14:45:14 | 显示全部楼层
学习
使用道具 举报

回复

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部