一, 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 这一项数值增长了, 则表明在丢包.
这里 http://www.withdevo.net/?p=18 有对 "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 的, 得看具体的业务了.
业务侧更关注的是响应时间.
来源: http://www.bubuko.com/infodetail-3195103.html