推荐: blog.csdn.net/aquester https://github.com/eyjian https://www.cnblogs.com/aquester http://blog.chinaunix.net/uid/20682147.html
全部博文（594）
分类： LINUX
2008-07-24 15:18:08
 |
|
工具介绍-Vmstat
Vmstat是一个很全面的性能分析工具，可以观察到系统的进程状态、内存使用、虚拟内存使用、磁盘的IO、中断、上下文切换、CPU使用等。系统性能分析工具中，使用最多的是这个，除了sysstat工具包外，这个工具能查看的系统资源最多。
主要说明这个命令显示出的部分数据代表的含义，和它反映出系统相关资源的状况。输出内容共有6类，分别说明如下。
b.Procs
– r: 运行的和等待(CPU时间片)运行的进程数，这个值也可以判断是否需要增加CPU(长期大于1)
– b: 处于不可中断状态的进程数，常见的情况是由IO引起的
c.Memory
– swpd: 切换到交换内存上的内存(默认以KB为单位)
• 如果 swpd 的值不为0，或者还比较大，比如超过100M了，但是 si, so 的值长期为 0，这种情况我们可以不用担心，不会影响系统性能。
– free: 空闲的物理内存
– buff: 作为buffer cache的内存，对块设备的读写进行缓冲
– cache: 作为page cache的内存, 文件系统的cache
• 如果 cache 的值大的时候，说明cache住的文件数多，如果频繁访问到的文件都能被cache住，那么磁盘的读IO bi会非常d.Swap
– si: 交换内存使用，由磁盘调入内存
– so: 交换内存使用，由内存调入磁盘
内存够用的时候，这2个值都是0，如果这2个值长期大于0时，系统性能会受到影响。磁盘IO和CPU资源都会被消耗。
有些人看到空闲内存(free)很少或接近于0时，就认为内存不够用了，实际上不能光看这一点的，还要结合si,so，如果free很少，但是si,so也很少(大多时候是0)，那么不用担心，系统性能这时不会受到影响的。
e. Io
• bi: 从块设备读入的数据总量(读磁盘) (KB/s)，
• bo: 写入到块设备的数据总理(写磁盘) (KB/s)
随机磁盘读写的时候，这2个值越大（如超出1M），能看到CPU在IO等待的值也会越大
f.System
– in: 每秒产生的中断次数
– cs: 每秒产生的上下文切换次数
上面这2个值越大，会看到由内核消耗的CPU时间会越多
g.Cpu
– us: 用户进程消耗的CPU时间百分比
• us 的值比较高时，说明用户进程消耗的CPU时间多，但是如果长期超过50% 的使用，那么我们就该考虑优化程序算法或者进行加速了(比如 PHP/Perl)
– sy: 内核进程消耗的CPU时间百分比
• sy 的值高时，说明系统内核消耗的CPU资源多，这并不是良性的表现，我们应该检查原因。
– wa: IO等待消耗的CPU时间百分比
• wa 的值高时，说明IO等待比较严重，这可能是由于磁盘大量作随机访问造成，也有可能是磁盘的带宽出现瓶颈(块操作)。
– id: CPU处在空闲状态时间百分比
h.情景分析 这个vmstat的输出那些信息值得关注？
– Procs r: 运行的进程比较多，系统很繁忙
– Io bo: 磁盘写的数据量稍大，如果是大文件的写，10M以内基本不用担心，如果是小文件写2M以内基本正常
– Cpu us: 持续大于50，服务高峰期可以接受
– Cpu wa: 稍微有些高
– Cpu id:持续小于50，服务高峰期可以接受
工具介绍-top
这个命令可以查看系统中运行的进程的状况，CPU使用状况，系统负载，内存使用等。它是检查系统进程运行状况最方便的工具了，它默认显示部分活动的进程，并且按照进程使用CPU的多少排序。它可以显示全部CPU的使用状况，也可以显示每个进程都运行在那个CPU上面。
习惯使用这个命令查看那些进程或者那类进程占用CPU和内存资源最多，以此迅速定位存在性能问题的进程，以及运行异常的进程。
– actv active 活跃的内存页，正在映射给进程使用。
– in_d inactive_dirty 非活跃的内存页，并且内存数据被修改，需要写回磁盘。
– in_c inactive_clean 非活跃的内存页，干净的数据，可以被重新分配使用。
4.问题in_d和in_c以及 cache, buffer的内存有何不同？
解释：actv, in_d, in_c 是 VM 中对内存的管理组织形式，buffer是块设备读写缓冲，cache是文件系统缓存。
5.用top看到的进程所处的几种状态(STAT列)。
– D 不可中断休眠，通常是 IO 操作所处的状态
– R 正在执行的或者处在等待执行的进程队列中
– S 休眠中
– T 暂停刮起的（比如Ctrl+Z），也可能是被 strace 命令调用中的状态
– Z 僵尸进程，进程执行完成，但由于其父进程没有销毁该进程，而被init进程接管进行销毁。
– W 没有使用物理内存，所占用的物理内存被切换到交换内存
– < 高优先级的进程
– N 低优先级
有时候一个进程会有多个状态的标志，比如SWN，SW
6.情景分析
前面两次top的输出那些信息值得关注？
– 图1)
• Load average: 系统负载有降低的趋势，但仍然较高
• Running: 有3个进程正在运行，正常，因为系统有4颗CPU
• Cpu user: 接近200%了，有些大，服务高峰时可以接受
• Cpu idle: 小于200%了，需要注意
– 图2)
– Cpu iowait:接近200%了，很大
工具介绍-free
free命令显示系统内存的使用状况（物理内存和交换内存），通过这个命令我们可以看到系统进程实际使用的物理内存，buffer和cache使用的物理内存。
a. free命令输出的第二行(Mem)
这行分别显示了物理内存的总量(total)、已使用的(used)、空闲的(free)、共享的(shared)、buffer、cache的内存。
b. free命令输出的第三行(-/+ buffers/cache) 这行最容易让人迷惑。
它显示的第一个值（used这一列）是这样得来的：
Mem行used列 - Mem行buffers列 - Mem行cached列
它显示的第二个值（free这一列）是这样得来的：
Mem行free列 + Mem行buffers列 + Mem行cached列
c. free命令输出的第四行(Swap) 这行显示交换内存的总量、已使用量、空闲量
通常 buffer 和 cache 可以使用的内存空间越大，系统 IO 和 文件系统访问的性能越好。
工具介绍-uptime
最简便的查看系统负载的工具，系统负载越小，系统运行状况越好，对于系统负载处在什么范围内比较合适，是没有定论的。
一般以15分钟负载的值来评估系统的健康度，以10为这个值的临界点，如果系统负载持续高于10，通常是存在某个资源长期紧张的原因，我们需要重视，并且得开始着手解决这个问题了。
如果偶尔高于10，应该开始留意它出现的频度，这往往是前面一种状况的先兆。
工具介绍-sysstat工具包
这个工具包提供了著名的 sar 命令，还有非常实用的 iostat, mpstat, sa1, sa2 等命令。
这几个命令可实现前面提及工具大多数的功能，除此之外，还能查看系统的网络带宽状况、每块磁盘使用状况、每个磁盘分区的使用状况等。
sa1, sa2 这2个命令以配置在cron中定期执行，把系统当时的运行状况信息保存在磁盘上，每日存在一个文件中，因为有这个功能，因此 sar 工具不单是一个性能分析的工具，这2个命令的使用说明如下：
sa1 配置在cron中可以实现系统状态收集，比如10分钟运行一次
sa2 配置在cron中可以实现每日状态的汇总报告
你可以在系统crontab中添加如下配置：
*/10 * * * * root /usr/lib/sa/sa1 1 1
53 23 * * * root /usr/lib/sa/sa2 -A
工具介绍-其他
a. Iozone IO和文件系统性能测试的工具，我也习惯用它作存储系统的性能分析。
b. Strace 如果我们知道一个程序执行效率很差，需要分析这个程序执行时的某个阶段或者某个系统调用的性能状况，可以使用 strace 命令。
附录：性能分析及优化的案例
1. 动态内容为主的网站
该网站系统结构说明
a. 1台Dell2650服务器, 单颗Xeon 3.0G CPU，1G内存，2块72G SCSI磁盘
b. 操作系统 CentOS 3.3
c. 应用基于LAMP架构，所有服务都在一台服务器上
分析和优化的过程
a. 初期性能问题及处理
i. 表现：早晨和下午访问高峰时，服务器频繁宕机，重启后的一段时间内能正常服务，过一会以后又变的响应缓慢，然后又宕机。
ii. 检查：发现宕机前系统负载高，Apache httpd.conf 配置最大用户数为1024。
iii. 处理：修改 httpd.conf 配置文件，降到最大 512 个用户数，仍然频繁宕机，又降到 256 个用户数，系统不宕机了，但是负载很高，站点访问极慢。
b. 初次优化
深入分析系统资源使用情况(vmstat,top,ps)
i. 结论：CPU资源时常耗尽，因此造成响应缓慢或者长时间没有响应，主要是用户进程消耗资源严重。
ii. 原因：PHP程序没有使用代码加速，网站首页是个PHP程序，每次用户访问都要多次查询数据库，其他程序也没有Cache机制，数据库查询负荷过高。
iii. 处理：安装配置turck-mmcache代码加速器，改写网站首页以及部分频繁访问的程序增加cache机制，减少数据库访问。
c. 第二次优化
一段时间后，系统又开始不稳定，访问高峰时站点无法正常访问
i. 分析系统资源使用状况，发现仍然是CPU耗尽后引起问题，但这次系统IO等待消耗的CPU资源比较大。
ii. 原因：上次解决了CPU资源容易耗尽的问题，目前网站访问量增加了，apache进程数时常达到256个，导致内存使用殆尽，频繁使用交换内存，最终仍然导致CPU资源耗尽
iii. 处理：把Apache配置中的 KeepAlive 特性关闭，进程数大量减少，基本保持在80个进程以内，还是会使用交换内存，但是服务正常了。
d. 第三次优化
一段时间后，系统又开始不稳定，访问高峰时站点无法正常访问
i. 分析发现还是CPU资源耗尽导致的原因。
ii. 原因：程序频繁访问数据库，大量的SQL语句中有 where, order by 等子句，而大量的表没有建索引，导致MySQL数据库负荷过高，消耗CPU资源过高。
iii. 处理：优化程序中的SQL语句，where和order by子句上的字段建索引，程序增加Cache机制，再次使服务恢复正常。
e. 第四次优化
一段时间后，系统又开始不稳定，访问高峰时站点无法正常访问
i. 分析系统资源使用状况，发现还是CPU耗尽造成的。
ii. 原因：数据库查询过多，大部分都是复杂查询，时常需要遍历全表。
iii. 处理：优化程序中的SQL语句，增加where子句上的匹配条件，减少遍历全部的查询。
f. 网站结构优化
i. 鉴于程序的优化空间越来越小，避免以后仍然出现问题，增加了一台专用数据库服务器。
ii. 在后来的使用过程中，又陆续增加了1台Web前端服务器，和一台只用于读的MySQL数据库服务器。
2. 动态内容+Cache为主的网站
该网站系统结构说明
a. 多台Web前端服务器, 配置都为单颗Xeon 3.0G CPU，4G内存，2块73G SCSI磁盘
b. 操作系统 CentOS 3.3
c. 多台MySQL数据库服务器
d. 基于PHP开发的应用
该应用的特点
a. 大量内容基于数据库，需要频繁访问数据库，并且数据更新很快
b. 采用页面cache机制缓解数据库压力，但页面cache只有5分钟有效期，需要频繁生成新的cache
c. Cache以文件形式存在磁盘上，都是小文件，最小不到1k，最大不超过128k
问题描述
a. 访问高峰期时Web前端负载比较高，时常超过10
b. 访问高峰期时Web前端响应很慢
性能分析
a. 负载比较高，时常会超过10，CPU Idel经常会小于30%，有时Idel为0，CPU io wait 很大，经常超过30%，磁盘读每秒不超过100k，磁盘写每秒1.5M左右，磁盘tps超过100
b. 访问高峰期时内存也有部分空闲，用于buffer和cache的内存基本占总内存60%以上，没有使用交换内存
原因分析
a. 分析该应用的特点后发现，访问高峰期时，要频繁生成新的cache文件，或者更新以及过期的cache文件，cache文件目录为256x256的哈希结构，因此读写文件时磁盘随机寻址非常频繁
b. 该应用磁盘写远大于磁盘读的原因是系统cache命中率高，大量文件读过一次就cache住了，因此读的开销很小
c. 写磁盘的量并不算很大，平均每秒1.5M，但都是随机写，因此写磁盘速度会稍微慢，也因此会消耗大量CPU时间
d. 对比访问高峰期和访问量小时候的系统状态，磁盘写的tps提高了1倍以上，CPU io wait提高了3倍以上，因此认为主要性能瓶颈在磁盘写上
优化办法
a. 减少磁盘写的次数，cache文件先写在内存中，超过一定访问次数时才写回磁盘，但由于要修改应用程序，因此执行难度大
b. 减少磁盘随机写的次数，前端不使用255x255的哈希目录，而是把多个cache文件写在一个大的cache文件中，并且只作追加写，这样就能把随机写变成了顺序写，cache过期后，整个大的cache文件可以一次删除。但由于要修改应用，因此执行难度大
c. 上面2个办法结合使用，听上去性能会更好，但是执行难度更大
d. 使用tmpfs作cache磁盘(ramdisk也可以)，这样写都在访问内存，没有磁盘IO消耗，缺点是cache的空间不会很大，不能超过2G(该服务器是4G内存)，但是不用修改应用程序，执行容易：
i. Mount –bind /dev/shm /var/www/cache
ii. 写一个清cache的脚本程序，配置在cron中，30分钟执行一次，检查/dev/shm的使用率超过70%时，使用find命令找出太旧的cache文件删除掉，最终采用了这个办法，高峰期系统负载小于5。
参考文章：
1.
2.
3.
