《Ourlinux》杂志

Linux System and Performance Monitoring(总结篇)
Date: 2009.07.21
Author: Darren Hoch
译: Tonnyom[AT]hotmail.com

接前4篇：

Linux System and Performance Monitoring(CPU篇)

Linux System and Performance Monitoring(Memory篇)

Linux System and Performance Monitoring(I/O篇)

Linux System and Performance Monitoring(Network篇)

结束语: 这是该译文的最后一篇,在这篇中,作者提供了一个案例环境,用之前几篇所阐述的理论以及涉及到的工具,对其进行一个整体的系统性能检查.对大家更好理解系统性能监控,进行一次实战演习.
BTW:在中文技术网站上,类似内容的文章,大体是来自该作者06-07年所著论文,此译文是建立在作者为OSCON 2009重写基础上的.所以部分内容可能会存在重复雷同,特此说明下.

附录 A: 案例学习 - 性能监控之循序渐进

某一天,一个客户打电话来需要技术帮助,并抱怨平常15秒就可以打开的网页现在需要20分钟才可以打开.

具体系统配置如下:

RedHat Enterprise Linux 3 update 7
Dell 1850 Dual Core Xenon Processors, 2 GB RAM, 75GB 15K Drives
Custom LAMP software stack(译注:Llinux+apache+mysql+php 环境)

性能分析之步骤

1. 首先使用vmstat 查看大致的系统性能情况:

# vmstat 1 10
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 249844 19144 18532 1221212 0 0 7 3 22 17 25 8 17 18
0 1 249844 17828 18528 1222696 0 0 40448 8 1384 1138 13 7 65 14
0 1 249844 18004 18528 1222756 0 0 13568 4 623 534 3 4 56 37
2 0 249844 17840 18528 1223200 0 0 35200 0 1285 1017 17 7 56 20
1 0 249844 22488 18528 1218608 0 0 38656 0 1294 1034 17 7 58 18
0 1 249844 21228 18544 1219908 0 0 13696 484 609 559 5 3 54 38
0 1 249844 17752 18544 1223376 0 0 36224 4 1469 1035 10 6 67 17
1 1 249844 17856 18544 1208520 0 0 28724 0 950 941 33 12 49 7
1 0 249844 17748 18544 1222468 0 0 40968 8 1266 1164 17 9 59 16
1 0 249844 17912 18544 1222572 0 0 41344 12 1237 1080 13 8 65 13

分析:
1,不会是内存不足导致,因为swapping 始终没变化(si 和 so).尽管空闲内存不多(free),但swpd 也没有变化.
2,CPU 方面也没有太大问题,尽管有一些运行队列(procs r),但处理器还始终有50% 多的idle(CPU id).
3,有太多的上下文切换(cs)以及disk block从RAM中被读入(bo).
4,CPU 还有平均20% 的I/O 等待情况.

结论:
从以上总结出,这是一个I/O 瓶颈.

2. 然后使用iostat 检查是谁在发出IO 请求:

# iostat -x 1
Linux 2.4.21-40.ELsmp (mail.example.com) 03/26/2007

avg-cpu: %user %nice %sys %idle
30.00 0.00 9.33 60.67

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 7929.01 30.34 1180.91 14.23 7929.01 357.84 3964.50 178.92 6.93 0.39 0.03 0.06 6.69
/dev/sda1 2.67 5.46 0.40 1.76 24.62 57.77 12.31 28.88 38.11 0.06 2.78 1.77 0.38
/dev/sda2 0.00 0.30 0.07 0.02 0.57 2.57 0.29 1.28 32.86 0.00 3.81 2.64 0.03
/dev/sda3 7929.01 24.58 1180.44 12.45 7929.01 297.50 3964.50 148.75 6.90 0.32 0.03 0.06 6.68

avg-cpu: %user %nice %sys %idle
9.50 0.00 10.68 79.82

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 0.00 0.00 1195.24 0.00 0.00 0.00 0.00 0.00 0.00 43.69 3.60 0.99 117.86
/dev/sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda3 0.00 0.00 1195.24 0.00 0.00 0.00 0.00 0.00 0.00 43.69 3.60 0.99 117.86

avg-cpu: %user %nice %sys %idle
9.23 0.00 10.55 79.22

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 0.00 0.00 1200.37 0.00 0.00 0.00 0.00 0.00 0.00 41.65 2.12 0.99 112.51
/dev/sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda3 0.00 0.00 1200.37 0.00 0.00 0.00 0.00 0.00 0.00 41.65 2.12 0.99 112.51

分析:
1,看上去只有/dev/sda3 分区很活跃,其他分区都很空闲.
2,差不多有1200 读IOPS,磁盘本身是支持200 IOPS左右(译注:参考之前的IOPS 计算公式).
3,有超过2秒,实际上没有一个读磁盘(rkb/s).这和在vmstat 看到有大量I/O wait是有关系的.
4,大量的read IOPS(r/s)和在vmstat 中大量的上下文是匹配的.这说明很多读操作都是失败的.

结论:
从以上总结出,部分应用程序带来的读请求,已经超出了I/O 子系统可处理的范围.

3. 使用top 来查找系统最活跃的应用程序

# top -d 1
11:46:11 up 3 days, 19:13, 1 user, load average: 1.72, 1.87, 1.80
176 processes: 174 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 12.8% 0.0% 4.6% 0.2% 0.2% 18.7% 63.2%
cpu00 23.3% 0.0% 7.7% 0.0% 0.0% 36.8% 32.0%
cpu01 28.4% 0.0% 10.7% 0.0% 0.0% 38.2% 22.5%
cpu02 0.0% 0.0% 0.0% 0.9% 0.9% 0.0% 98.0%
cpu03 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100.0%
Mem: 2055244k av, 2032692k used, 22552k free, 0k shrd, 18256k buff
1216212k actv, 513216k in_d, 25520k in_c
Swap: 4192956k av, 249844k used, 3943112k free 1218304k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14939 mysql 25 0 379M 224M 1117 R 38.2 25.7% 15:17.78 mysqld
4023 root 15 0 2120 972 784 R 2.0 0.3 0:00.06 top
1 root 15 0 2008 688 592 S 0.0 0.2 0:01.30 init
2 root 34 19 0 0 0 S 0.0 0.0 0:22.59 ksoftirqd/0
3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.05 events/0

分析:
1,占用资源最多的好像就是mysql 进程,其他都处于完全idle 状态.
2,在top(wa) 看到的数值,和在vmstat 看到的wio 数值是有关联的.

结论:
从以上总结出,似乎就只有mysql 进程在请求资源,因此可以推论它就是导致问题的关键.

4. 现在已经确定是mysql 在发出读请求,使用strace 来检查它在读请求什么.

# strace -p 14939

Process 14939 attached - interrupt to quit
read(29, “\3\1\237\1\366\337\1\222%\4\2\0\0\0\0\0012P/d”, 20) = 20
read(29, “ata1/strongmail/log/strongmail-d”…, 399) = 399
_llseek(29, 2877621036, [2877621036], SEEK_SET) = 0
read(29, “\1\1\241\366\337\1\223%\4\2\0\0\0\0\0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 400) = 400
_llseek(29, 2877621456, [2877621456], SEEK_SET) = 0
read(29, “\1\1\235\366\337\1\224%\4\2\0\0\0\0\0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 396) = 396
_llseek(29, 2877621872, [2877621872], SEEK_SET) = 0
read(29, “\1\1\245\366\337\1\225%\4\2\0\0\0\0\0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 404) = 404
_llseek(29, 2877622296, [2877622296], SEEK_SET) = 0
read(29, “\3\1\236\2\366\337\1\226%\4\2\0\0\0\0\0012P/d”, 20) = 20

分析:
1,大量的读操作都在不断寻道中,说明mysql 进程产生的是随机IO.
2,看上去似乎是,某一sql 查询导致读操作.

结论:
从以上总结出,所有的读IOPS 都是mysql 进程在执行某些读查询时产生的.

5. 使用mysqladmin 命令,来查找是哪个慢查询导致的.

# ./mysqladmin -pstrongmail processlist

+—-+——+———–+————+———+——+———-+—————————————-
| Id | User | Host | db | Command | Time | State | Info
+—-+——+———–+————+———+——+———-+—————————————-
| 1 | root | localhost | strongmail | Sleep | 10 | |
| 2 | root | localhost | strongmail | Sleep | 8 | |
| 3 | root | localhost | root | Query | 94 | Updating | update `failures` set
`update_datasource`=’Y’ where database_id=’32′ and update_datasource=’N’ and |
| 14 | root | localhost | | Query | 0 | | show processlist

分析:
1,MySQL 数据库里,似乎在不断的运行table update查询.
2,基于这个update 查询,数据库是对所有的table 进行索引.

结论:
从以上总结出,MySQL里这些update 查询问题,都是在尝试对所有table 进行索引.这些产生的读请求正是导致系统性能下降的原因.

后续

把以上这些性能信息移交给了相关开发人员,用于分析他们的PHP 代码.一个开发人员对代码进行了临时性优化.某个查询如果出错了,也最多到100K记录.数据库本身考虑最多存在4百万记录.最后,这个查询不会再给数据库带来负担了.

References
• Ezlot, Phillip – Optimizing Linux Performance, Prentice Hall, Princeton NJ 2005 ISBN – 0131486829
• Johnson, Sandra K., Huizenga, Gerrit – Performance Tuning for Linux Servers, IBM Press, Upper Saddle River NJ 2005 ISBN 013144753X
• Bovet, Daniel Cesati, Marco – Understanding the Linux Kernel, O’Reilly Media, Sebastoppl CA 2006, ISBN 0596005652
• Blum, Richard – Network Performance Open Source Toolkit, Wiley, Indianapolis IN 2003, ISBN 0-471-43301-2
• Understanding Virtual Memory in RedHat 4, Neil Horman, 12/05 http://people.redhat.com/nhorman/papers/rhel4_vm.pdf
• IBM, Inside the Linux Scheduler, http://www.ibm.com/developerworks/linux/library/l-scheduler/
• Aas, Josh, Understanding the Linux 2.6.8.1 CPU Scheduler, http://josh.trancesoftware.com/linux/linux_cpu_scheduler.pdf
• Wieers, Dag, Dstat: Versatile Resource Statistics Tool, http://dag.wieers.com/home-made/dstat/

上一篇：

Linux System and Performance Monitoring(Network篇)

同事力作，原文见：http://tonnyom.yo2.cn/2009/08/14/linux-system-and-performance-monitoring%E6%80%BB%E7%BB%93%E7%AF%87/

Linux System and Performance Monitoring(CPU篇)
Date:         2009.07.21
Author:    Darren Hoch
译:            Tonnyom[AT]hotmail.com 2009.08.10

前言: 网上其实有很多关于这方面的文章,那为什么还会有此篇呢,有这么几个原因,是我翻译的动力,第一,概念和内容虽然老套,但都讲得很透彻,而且还很全面.第二,理论结合实际,其中案例分析都不错.第三,不花哨,采用的工具及命令都是最基本的,有助于实际操作.但本人才疏学浅,译文大多数都是立足于自己对原文的理解,大家也可以自己去OSCAN上找原文,如果有什么较大出入,还望留言回复,甚是感激!

1.0 性能监控介绍

性能优化就是找到系统处理中的瓶颈以及去除这些的过程,多数管理员相信看一些相关的”cook book”就可以实现性能优化,通常通过对内核的一些配置是可以简单的解决问题,但并不适合每个环境,性能优化其实是对OS 各子系统达到一种平衡的定义,这些子系统包括了:

CPU
Memory
IO
Network

这些子系统之间关系是相互彼此依赖的,任何一个高负载都会导致其他子系统出现问题.比如:

大量的页调入请求导致内存队列的拥塞
网卡的大吞吐量可能导致更多的 CPU开销
大量的CPU开销又会尝试更多的内存使用请求
大量来自内存的磁盘写请求可能导致更多的 CPU 以及 IO问题
所以要对一个系统进行优化,查找瓶颈来自哪个方面是关键,虽然看似是某一个子系统出现问题,其实有可能是别的子系统导致的.

1.1 确定应用类型

基于需要理解该从什么地方来入手优化瓶颈,首先重要的一点,就是理解并分析当前系统的特点,多数系统所跑的应用类型,主要为2种:

IO Bound(译注:IO 范畴): 在这个范畴中的应用,一般都是高负荷的内存使用以及存储系统,这实际上表示IO 范畴的应用,就是一个大量数据处理的过程.IO 范畴的应用不对CPU以及网络发起更多请求(除非类似NAS这样的网络存储硬件).IO 范畴的应用通常使用CPU 资源都是为了产生IO 请求以及进入到内核调度的sleep 状态.通常数据库软件(译注:mysql,oracle等)被认为是IO 范畴的应用类型.

CPU Bound(译注:CPU 范畴): 在这个范畴中的应用,一般都是高负荷的CPU 占用. CPU 范畴的应用,就是一个批量处理CPU 请求以及数学计算的过程.通常web server,mail server,以及其他类型服务被认为是CPU 范畴的应用类型.

1.2 确定基准线统计

系统利用率情况,一般随管理员经验以及系统本身用途来决定.唯一要清楚的就是,系统优化希望达成什么效果,以及哪些方面是需要优化,还有参考值是什么?因此就建立一个基准线,这个统计数据必须是系统可用性能状态值,用来比较不可用性能状态值.

在以下例子中,1个系统性能的基准线快照,用来比较当高负荷时的系统性能快照.

# vmstat 1
procs                      memory      swap          io     system         cpu
r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy wa id
1  0 138592  17932 126272 214244    0    0     1    18  109    19  2  1  1 96
0  0 138592  17932 126272 214244    0    0     0     0  105    46  0  1  0 99
0  0 138592  17932 126272 214244    0    0     0     0  198    62 40 14  0 45
0  0 138592  17932 126272 214244    0    0     0     0  117    49  0  0  0 100
0  0 138592  17924 126272 214244    0    0     0   176  220   938  3  4 13 80
0  0 138592  17924 126272 214244    0    0     0     0  358  1522  8 17  0 75
1  0 138592  17924 126272 214244    0    0     0     0  368  1447  4 24  0 72
0  0 138592  17924 126272 214244    0    0     0     0  352  1277  9 12  0 79

# vmstat 1
procs                      memory      swap          io     system         cpu
r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy wa id
2  0 145940  17752 118600 215592    0    1     1    18  109    19  2  1  1 96
2  0 145940  15856 118604 215652    0    0     0   468  789   108 86 14  0  0
3  0 146208  13884 118600 214640    0  360     0   360  498    71 91  9  0  0
2  0 146388  13764 118600 213788    0  340     0   340  672    41 87 13  0  0
2  0 147092  13788 118600 212452    0  740     0  1324  620    61 92  8  0  0
2  0 147360  13848 118600 211580    0  720     0   720  690    41 96  4  0  0
2  0 147912  13744 118192 210592    0  720     0   720  605    44 95  5  0  0
2  0 148452  13900 118192 209260    0  372     0   372  639    45 81 19  0  0
2  0 149132  13692 117824 208412    0  372     0   372  457    47 90 10  0  0

从上面第一个结果可看到,最后一列(id) 表示的是空闲时间,我们可以看到,在基准线统计时,CPU 的空闲时间在79% - 100%.在第二个结果可看到,系统处于100%的占用率以及没有空闲时间.从这个比较中,我们就可以确定是否是CPU 使用率应该被优化.

2.0 安装监控工具

多数 *nix系统都有一堆标准的监控命令.这些命令从一开始就是*nix 的一部分.Linux 则通过基本安装包以及额外包提供了其他监控工具,这些安装包多数都存在各个Linux 发布版本中.尽管还有其他更多的开源以及第三方监控软件,但本文档只讨论基于Linux 发布版本的监控工具.

本章将讨论哪些工具怎样来监控系统性能.

Tool          Description                      Base      Repository
vmstat      all purpose performance tool              yes      yes
mpstat      provides statistics per CPU              no      yes
sar          all purpose performance monitoring tool      no      yes
iostat      provides disk statistics              no      yes
netstat      provides network statistics              yes      yes
dstat          monitoring statistics aggregator          no      in most distributions
iptraf      traffic monitoring dashboard              no      yes
netperf      Network bandwidth tool              no      In some distributions
ethtool      reports on Ethernet interface configuration      yes      yes
iperf          Network bandwidth tool              no      yes
tcptrace      Packet analysis tool                  no      yes

3.0 CPU 介绍

CPU 利用率主要依赖于是什么资源在试图存取.内核调度器将负责调度2种资源种类:线程(单一或者多路)和中断.调度器去定义不同资源的不同优先权.以下列表从优先级高到低排列:

Interrupts(译注:中断) - 设备通知内核,他们完成一次数据处理的过程.例子,当一块网卡设备递送网络数据包或者一块硬件提供了一次IO 请求.

Kernel(System) Processes(译注:内核处理过程) - 所有内核处理过程就是控制优先级别.

User Processes(译注:用户进程) - 这块涉及”userland”.所有软件程序都运行在这个user space.这块在内核调度机制中处于低优先级.

从上面,我们可以看出内核是怎样管理不同资源的.还有几个关键内容需要介绍,以下部分就将介绍context(译注:上下文切换),run queues(译注:运行队列)以及utilization(译注:利用率).

3.1 上下文切换

多数现代处理器都能够运行一个进程(单一线程)或者线程.多路超线程处理器有能力运行多个线程.然而,Linux 内核还是把每个处理器核心的双核心芯片作为独立的处理器.比如,以Linux 内核的系统在一个双核心处理器上,是报告显示为两个独立的处理器.

一个标准的Linux 内核可以运行50 至 50,000 的处理线程.在只有一个CPU时,内核将调度并均衡每个进程线程.每个线程都分配一个在处理器中被开销的时间额度.一个线程要么就是获得时间额度或已抢先获得一些具有较高优先级(比如硬件中断),其中较高优先级的线程将从区域重新放置回处理器的队列中.这种线程的转换关系就是我们提到的上下文切换.

每次内核的上下文切换,资源被用于关闭在CPU寄存器中的线程和放置在队列中.系统中越多的上下文切换,在处理器的调度管理下,内核将得到更多的工作.

3.2 运行队列

每个CPU 都维护一个线程的运行队列.理论上,调度器应该不断的运行和执行线程.进程线程不是在sleep 状态中(译注:阻塞中和等待IO中)或就是在可运行状态中.如果CPU 子系统处于高负荷下,那就意味着内核调度将无法及时响应系统请求.导致结果,可运行状态进程拥塞在运行队列里.当运行队列越来越巨大,进程线程将花费更多的时间获取被执行.

比较流行的术语就是”load”,它提供当前运行队列的详细状态.系统 load 就是指在CPU 队列中有多少数目的线程,以及其中当前有多少进程线程数目被执行的组合.如果一个双核系统执行了2个线程,还有4个在运行队列中,则 load 应该为 6. top 这个程序里显示的load averages 是指1,5,15 分钟以内的load 情况.

3.3 CPU 利用率

CPU 利用率就是定义CPU 使用的百分比.评估系统最重要的一个度量方式就是CPU 的利用率.多数性能监控工具关于CPU 利用率的分类有以下几种:

User Time(译注:用户进程时间) - 关于在user space中被执行进程在CPU 开销时间百分比.

System Time(译注:内核线程以及中断时间) - 关于在kernel space中线程和中断在CPU 开销时间百分比.

Wait IO(译注:IO 请求等待时间) - 所有进程线程被阻塞等待完成一次IO 请求所占CPU 开销idle的时间百分比.

Idle(译注:空闲) - 一个完整空闲状态的进程在CPU 处理器中开销的时间百分比.

4.0 CPU 性能监控

理解运行队列,利用率,上下文切换对怎样CPU 性能最优化之间的关系.早期提及到,性能是相对于基准线数据的.在一些系统中,通常预期所达到的性能包括:

Run Queues -  每个处理器应该运行队列不超过1-3 个线程.例子,一个双核处理器应该运行队列不要超过6 个线程.

CPU Utiliation - 如果一个CPU 被充分使用,利用率分类之间均衡的比例应该是
65% - 70% User Time
30% - 35% System Time
0% - 5%   Idle Time

Context Switches - 上下文切换的数目直接关系到CPU 的使用率,如果CPU 利用率保持在上述均衡状态时,大量的上下文切换是正常的.

很多Linux 上的工具可以得到这些状态值,首先就是 vmstat 和 top 这2个工具.

4.1 vmstat 工具的使用

vmstat 工具提供了一种低开销的系统性能观察方式.因为 vmstat 本身就是低开销工具,在非常高负荷的服务器上,你需要查看并监控系统的健康情况,在控制窗口还是能够使用vmstat 输出结果.这个工具运行在2种模式下:average 和 sample 模式.sample 模式通过指定间隔时间测量状态值.这个模式对于理解在持续负荷下的性能表现,很有帮助.下面就是

vmstat 运行1秒间隔的示例:

# vmstat 1
procs ———–memory———- —swap– —–io—- –system– —-cpu—-
r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
0  0 104300  16800  95328  72200    0    0     5    26    7    14  4  1 95  0
0  0 104300  16800  95328  72200    0    0     0    24 1021    64  1  1 98  0
0  0 104300  16800  95328  72200    0    0     0     0 1009    59  1  1 98  0

Table 1:  The vmstat CPU statistics
Field          Description
r         The amount of threads in the run queue. These are threads that are runnable, but the CPU is not available to execute them.
当前运行队列中线程的数目.代表线程处于可运行状态,但CPU 还未能执行.
b          This is the number of processes blocked and waiting on IO requests to finish.
当前进程阻塞并等待IO 请求完成的数目
in          This is the number of interrupts being processed.
当前中断被处理的数目
cs          This is the number of context switches currently happening on the system.
当前kernel system中,发生上下文切换的数目
us          This is the percentage of user CPU utilization.
CPU 利用率的百分比
sys          This is the percentage of kernel and interrupts utilization.
内核和中断利用率的百分比
wa         This is the percentage of idle processor time due to the fact that ALL runnable threads are blocked waiting on IO.
所有可运行状态线程被阻塞在等待IO 请求的百分比
id          This is the percentage of time that the CPU is completely idle.
CPU 空闲时间的百分比

4.2 案例学习:持续的CPU 利用率

在这个例子中,这个系统被充分利用

# vmstat 1
procs                      memory      swap          io     system         cpu
r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy wa id
3  0 206564  15092  80336 176080    0    0     0     0  718    26 81 19  0  0
2  0 206564  14772  80336 176120    0    0     0     0  758    23 96  4  0  0
1  0 206564  14208  80336 176136    0    0     0     0  820    20 96  4  0  0
1  0 206956  13884  79180 175964    0  412     0  2680 1008    80 93  7  0  0
2  0 207348  14448  78800 175576    0  412     0   412  763    70 84 16  0  0
2  0 207348  15756  78800 175424    0    0     0     0  874    25 89 11  0  0
1  0 207348  16368  78800 175596    0    0     0     0  940    24 86 14  0  0
1  0 207348  16600  78800 175604    0    0     0     0  929    27 95  3  0  2
3  0 207348  16976  78548 175876    0    0     0  2508  969    35 93  7  0  0
4  0 207348  16216  78548 175704    0    0     0     0  874    36 93  6  0  1
4  0 207348  16424  78548 175776    0    0     0     0  850    26 77 23  0  0
2  0 207348  17496  78556 175840    0    0     0     0  736    23 83 17  0  0
0  0 207348  17680  78556 175868    0    0     0     0  861    21 91  8  0  1

根据观察值,我们可以得到以下结论:

1,有大量的中断(in) 和较少的上下文切换(cs).这意味着一个单一的进程在产生对硬件设备的请求.

2,进一步显示某单个应用,user time(us) 经常在85%或者更多.考虑到较少的上下文切换,这个应用应该还在处理器中被处理.

3,运行队列还在可接受的性能范围内,其中有2个地方,是超出了允许限制.

4.3 案例学习:超负荷调度

在这个例子中,内核调度中的上下文切换处于饱和

# vmstat 1
procs                      memory      swap          io     system         cpu
r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy wa id
2  1 207740  98476  81344 180972    0    0  2496     0  900  2883  4 12 57 27
0  1 207740  96448  83304 180984    0    0  1968   328  810  2559  8  9 83  0
0  1 207740  94404  85348 180984    0    0  2044     0  829  2879  9  6 78  7
0  1 207740  92576  87176 180984    0    0  1828     0  689  2088  3  9 78 10
2  0 207740  91300  88452 180984    0    0  1276     0  565  2182  7  6 83  4
3  1 207740  90124  89628 180984    0    0  1176     0  551  2219  2  7 91  0
4  2 207740  89240  90512 180984    0    0   880   520  443   907 22 10 67  0
5  3 207740  88056  91680 180984    0    0  1168     0  628  1248 12 11 77  0
4  2 207740  86852  92880 180984    0    0  1200     0  654  1505  6  7 87  0
6  1 207740  85736  93996 180984    0    0  1116     0  526  1512  5 10 85  0
0  1 207740  84844  94888 180984    0    0   892     0  438  1556  6  4 90  0

根据观察值,我们可以得到以下结论:

1,上下文切换数目高于中断数目,说明kernel中相当数量的时间都开销在上下文切换线程.

2,大量的上下文切换将导致CPU 利用率分类不均衡.很明显实际上等待io 请求的百分比(wa)非常高,以及user time百分比非常低(us).

3,因为CPU 都阻塞在IO请求上,所以运行队列里也有相当数目的可运行状态线程在等待执行.

4.4 mpstat 工具的使用

如果你的系统运行在多处理器芯片上,你可以使用 mpstat 命令来监控每个独立的芯片.Linux 内核视双核处理器为2 CPU’s,因此一个双核处理器的双内核就报告有4 CPU’s 可用.

mpstat 命令给出的CPU 利用率统计值大致和 vmstat 一致,但是 mpstat 可以给出基于单个处理器的统计值.

# mpstat –P ALL 1
Linux 2.4.21-20.ELsmp (localhost.localdomain)   05/23/2006

05:17:31 PM  CPU   %user   %nice %system   %idle    intr/s
05:17:32 PM  all    0.00    0.00    3.19   96.53     13.27
05:17:32 PM    0    0.00    0.00    0.00  100.00      0.00
05:17:32 PM    1    1.12    0.00   12.73   86.15     13.27
05:17:32 PM    2    0.00    0.00    0.00  100.00      0.00
05:17:32 PM    3    0.00    0.00    0.00  100.00      0.00

4.5 案例学习: 未充分使用的处理量

在这个例子中,为4 CPU核心可用.其中2个CPU 主要处理进程运行(CPU 0 和1).第3个核心处理所有内核和其他系统功能(CPU 3).第4个核心处于idle(CPU 2).

使用 top 命令可以看到有3个进程差不多完全占用了整个CPU 核心.

# top -d 1
top - 23:08:53 up  8:34,  3 users,  load average: 0.91, 0.37, 0.13
Tasks: 190 total,   4 running, 186 sleeping,   0 stopped,   0 zombie
Cpu(s): 75.2% us,  0.2% sy,  0.0% ni, 24.5% id,  0.0% wa,  0.0% hi,  0.0%
si
Mem:   2074736k total,   448684k used,  1626052k free,    73756k buffers
Swap:  4192956k total,        0k used,  4192956k free,   259044k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
15957 nobody    25   0  2776  280  224 R  100  20.5  0:25.48 php
15959 mysql     25   0  2256  280  224 R  100  38.2  0:17.78 mysqld
15960 apache    25   0  2416  280  224 R  100  15.7  0:11.20 httpd
15901 root      16   0  2780 1092  800 R    1  0.1   0:01.59 top
1 root      16   0  1780  660  572 S    0  0.0   0:00.64 init

# mpstat –P ALL 1
Linux 2.4.21-20.ELsmp (localhost.localdomain)   05/23/2006

05:17:31 PM  CPU   %user   %nice %system   %idle    intr/s
05:17:32 PM  all   81.52    0.00   18.48   21.17    130.58
05:17:32 PM    0   83.67    0.00   17.35    0.00    115.31
05:17:32 PM    1   80.61    0.00   19.39    0.00     13.27
05:17:32 PM    2    0.00    0.00   16.33   84.66      2.01
05:17:32 PM    3   79.59    0.00   21.43    0.00      0.00

05:17:32 PM  CPU   %user   %nice %system   %idle    intr/s
05:17:33 PM  all   85.86    0.00   14.14   25.00    116.49
05:17:33 PM    0   88.66    0.00   12.37    0.00    116.49
05:17:33 PM    1   80.41    0.00   19.59    0.00      0.00
05:17:33 PM    2    0.00    0.00    0.00  100.00      0.00
05:17:33 PM    3   83.51    0.00   16.49    0.00      0.00

05:17:33 PM  CPU   %user   %nice %system   %idle    intr/s
05:17:34 PM  all   82.74    0.00   17.26   25.00    115.31
05:17:34 PM    0   85.71    0.00   13.27    0.00    115.31
05:17:34 PM    1   78.57    0.00   21.43    0.00      0.00
05:17:34 PM    2    0.00    0.00    0.00  100.00      0.00
05:17:34 PM    3   92.86    0.00    9.18    0.00      0.00

05:17:34 PM  CPU   %user   %nice %system   %idle    intr/s
05:17:35 PM  all   87.50    0.00   12.50   25.00    115.31
05:17:35 PM    0   91.84    0.00    8.16    0.00    114.29
05:17:35 PM    1   90.82    0.00   10.20    0.00      1.02
05:17:35 PM    2    0.00    0.00    0.00  100.00      0.00
05:17:35 PM    3   81.63    0.00   15.31    0.00      0.00

你也可以使用 ps 命令通过查看 PSR 这列,检查哪个进程在占用了哪个CPU.

# while :; do  ps -eo pid,ni,pri,pcpu,psr,comm | grep ‘mysqld’; sleep 1;
done
PID  NI PRI %CPU PSR COMMAND
15775   0  15 86.0   3 mysqld
PID  NI PRI %CPU PSR COMMAND
15775   0  14 94.0   3 mysqld
PID  NI PRI %CPU PSR COMMAND
15775   0  14 96.6   3 mysqld
PID  NI PRI %CPU PSR COMMAND
15775   0  14 98.0   3 mysqld
PID  NI PRI %CPU PSR COMMAND
15775   0  14 98.8   3 mysqld
PID  NI PRI %CPU PSR COMMAND
15775   0  14 99.3   3 mysqld

4.6 结论

监控 CPU 性能由以下几个部分组成:

1,检查system的运行队列,以及确定不要超出每个处理器3个可运行状态线程的限制.

2,确定CPU 利用率中user/system比例维持在70/30

3,当CPU 开销更多的时间在system mode,那就说明已经超负荷并且应该尝试重新调度优先级

4,当I/O 处理得到增长,CPU 范畴的应用处理将受到影响

下一篇：

Linux System and Performance Monitoring(Memory篇)

同事力作，原文见：http://tonnyom.yo2.cn/2009/08/10/linux-system-and-performance-monitoring-cpu/

看到这张图，我想对性能优化的主要矛盾和次要矛盾就很明了了，这里os的优化玛法是最轻的，也告知了我们最重的2个玛法（主要矛盾）是Application和Architecture and Design，下面怎么做就了然于胸了。

btw，虽然这个是和DB相关的，但是其它应用上的优化也是完全可以套用的——自勉之！

昨天在群里看到朋友分享的《提升可伸缩性的八项最佳实践》个人认为核心是减少延迟！

评价性能参数有以下4个指标：

1. 延迟
2. 吞吐量
3. 利用率
4. 效率

在排查问题或者设计的时候，如果将所有涉及到有延迟的地方全部整理出来，然后逐个解决延迟高的点，这样实践的点就会更多，这样也就提升了性能！

S2：性能参数

每个计算机系统都有4个传统的参数：

• 延迟

• 吞吐量

• 利用率

• 效率

优化系统性能就是要减少延迟、增加其他3个参数的值。尽管这个定义很直观，但优化本身并不直观，因为这些参数彼此之间可以互相消长，而且它们会随时间、服务内容种类已经许多其他环境改变而改变。另外，对某个机构的目标来说，有些性能参数比其他参数重要。 Read more »

1. 需要多大的带宽？

对web站点的性能来说，服务器带宽是为仪最重要的因素。实际上确定需要怎么样的带宽的数学公式非常简单：次／秒（每秒访问的次数）＊比特／次（每次访问的平均容量）＝比特／秒

2. 需要多快的服务器？

对绝大多数网站来说，处理静态文件的性能兵并不是瓶颈。
因特网上一个http传输的全部时间通常是2－20秒，其中大部分是由调制解调器和因特网带宽以及延迟限制带来的。

Read more »

Web服务器性能的主要指标：

1. 每秒处理的的请求数：req/s
2. 每个请求的响应时间：response time

提醒一下自己:)

一般来说，组成Web站点体系结构有如下几个基本元素。

浏览器

因为Web浏览器标准、简单且普遍使用，所以它可以称得上是一个接近理想状态的图形用户接口（Graphical User Interface，GUI）。
目前比较流行的浏览器有：IE，firefox，opera，safari等，所以必须要了解其的相关特性，这也利于更好的利用这些特性来做相关架构的设计。

负载均衡

最简单的莫属DNS轮询（Round Robin DNS）方式了，但是不建议使用，因为下面的三个原因迫使你特别小心：
1. Round Robin DNS无法实现真正的负载均衡，但是在一些简单情况下还是能够均衡负载。真正的负载均衡是监测服务器的使用情况，以及根据该使用情况来分配连接，以便能始终将连接分配给那些有足够的容量来处理这些连接的服务器。
当Round Robin集中的一台服务器比其他服务器慢很多时，就会产生一种称为”护航（convoying）“的特殊情况，这时用户会列队等待速度较慢的服务器，而较快的服务器则未被使用。真正的负载均衡不会出现这样的问题。
2. RRDNS不会视图解决服务器的失效问题。用户仍然会被引导到失效的服务器上。真正的负载均衡可以提高站点的可用性，因为如果一台服务器出现故障，那么其他的服务器会自动接过该服务器的负载。
3. RRDNS很难保持用户的状态，特别是使用session的业务，比如某个用户在发表文章或者回复的时候，应用程序会对该用户的session保存在当前的服务器上，但是当用户写好文章或者回复开始提交后，因为RRDNS，结果发现用户提交到了另外的服务器上，因为新的服务器上没有用户的session，提示用户未登陆等警告信息，所以会导致提交失败。
很多情况，情况当要从dns里删除失效的IP时，会发现DNS的更新非常慢，因为很多LOCAL DNS并不遵循相关规范，这样有许多用户的LOCAL DNS服务器的缓存里仍会保留这个失效的IP，而且保留的时候甚至会很久，在国内特别是小的ISP常会这么做。

IP级别的负载均衡
这里常见的软件的实现方式有LVS，值得骄傲的是LVS是由国人章文嵩开发的，其简单高效，当然也需要配合其他的HA软件来实现”三H“。通过IP级别的负载均衡可以避免上述的RRDNS弊端。

当然也可以使用硬件均衡设备。

Web服务器

目前常用开源的Web服务器有：Apache、Nginx、Lighttpd等。
Web服务器的内容和日志应当分开保存到各自专用的磁盘上，这样可以避免他们相互干扰。

中间件

任何与一端的Web服务器和另一端的数据库交互的软件都可以被成为中间件。中间件的好处可以使结构清晰简单，可以提高整体性能。

数据库

数据库表可以通过某种方式被定义、镜像、分割、部署，以使之发挥最大的性能。数据库的优化是们深奥的学问，一个好的数据库管理员（Database Administrator，DBA）身价也是不菲的。
目前常见的DB有：mysql、oracle等。

虽然Web站点体系基本上是上述几个方面，但是影响Web性能确有更多的因素，只要把握上述几个方面，逐步排除和优化，我想结果一定不会差。

做个标记:)

Httperf is a tool for measuring web server performance. It provides a flexible facility for generating various HTTP workloads and for measuring server performance. The focus of httperf is not on implementing one particular benchmark but on providing a robust, high-performance tool that facilitates the construction of both micro- and macro-level benchmarks. The three distinguishing characteristics of httperf are its robustness, which includes the ability to generate and sustain server overload, support for the HTTP/1.1 and SSL protocols, and its extensibility to new workload generators and performance measurements.

Httperf 是一个高效的 http 压力测试工具，使用它可以模拟出超过1千的并发访问，能充分测试出 web server 的性能。而之前使用的 siege 测试工具则未能突破 500 个并发测试（如果您知道如何可以实现，请告诉我）

Read more »