关于应用系统的性能优化

一、性能优化的目标

      性能优化的目标是在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡，因为任何一项资源的过渡使用都会造成平衡体系破坏，从而造成系统负载极高或者响应迟缓。

二、性能分析的参与人员

     1）系统设计师

     了解系统架构中的性能瓶颈，便于优化系统结构；

     2）系统管理员

     了解系统资源的使用情况（硬件）；了解系统运行状况(负载)；应用程序对资源的使用情况(应用程序执行效率）；针对性的开展服务器性能优化(硬件、软件、软件配置)等；

     3）软件开发工程师

     了解系统的执行效率；改进程序的处理逻辑，优化系统性能；

三、性能相关的方面

     1）硬件资源

      CPU:

      1、是否使用SMP（SMP的全称是"对称多处理"（Symmetrical Multi-Processing）技术，是指在一个计算机上汇集了一组处理器(多CPU),各CPU之间共享内存子系统以及总线结构）

      内存：

      1、物理内存不足的情况下会使用虚拟内存   2、虚拟内存会带来磁盘IO和CPU的开销增加

      存储系统：

      1、SCSI磁盘 2、ATA/SATA磁盘 3、RAID磁盘阵列(RAID0, RAID1, RAID5, RAID0+1)

      2、经验：小文件读写的性能瓶颈是磁盘的寻址（随机读写性能更差），评估的标准是tps；大文件读写的性能瓶颈是带宽，评估的标准是持续的读写速度；Linux可以利用空闲内存作文件系统访问的cache，因此系统内存越大存储系统的性能也越好；

      网络带宽：1、网络带宽 2、SCSI总线带宽（注意大文件访问）3、系统总线带宽

     2）操作系统 1、SMP性能 2、VM性能 3、IO性能 4、文件系统性能(大文件优化、小文件优化、写优化、读优化、网络文件系统)

     3）服务器软件

     4）开发平台/应用中间件

     5）应用系统

四、优化原则

     1）程序的优化和系统结构的优化比硬件的性能优化更有效；2）避免不受限制的使用系统资源（设置各项服务对资源的使用限额，如Apache, MySQL,PHP等）3）对资源的使用状况作长期的监控和数据收集；4）始终保留一定量的空闲资源；日常情况下，保留至少 60% 的系统资源，以应付突发使用增长。日常情况下，资源使用率达到 80% 时，你必须有所行动了，尤其是web应用；5）系统硬件达到合理的配置（以适合应用的特点为依据，资源消耗均衡为目标）6）应用软件对资源的使用要均衡：理想状况为：CPU消耗到50%的时候，磁盘的带宽也到50%，磁盘的tps也到50%，内存使用也到50%

五、出现性能问题的主要方面

    大多数的硬件性能问题主要和CPU、磁盘、内存相关，应用程序设计的缺陷和数据库查询的滥用是最常见的性能问题；虽然性能瓶颈是程序性能差或内存不足或磁盘瓶颈等各种原因，但最终表现是CPU耗尽，系统负载高，响应迟缓，甚至暂时失去响应，因此我们观察服务器状况时，最先看的就是系统负载和CPU空闲度。

    1、动态内容应用：1）频繁执行程序，消耗CPU严重；2）并发用户访问，因此系统进程数多，消耗内存多，当内存不足时，使用虚拟内存也会增加CPU的开销 3）磁盘写IO比较频繁（主要为随机写），比如生成cache文件，更新session文件等 4）内存充足时读取的内容可以被cache住，cache的命中率和文件更新的频繁程度成反比，磁盘的读IO相对较小

    2）静态内容应用：1）网络带宽瓶颈 2）小文件的随机读取频繁，内存充足时可以缓解磁盘随机读的压力；系统内存不足时磁盘IO量会比较大（读、写、交换内存），因此增加CPU的开销；

    3）数据库应用：1）数据库查询语句复杂，大量的 where 子句，order by, group by 排序等 2）表太大时，查询遍历全表造成磁盘读的IO量大，容易出现读IO等待的情况 3）数据更新量大或者更新频繁时，造成磁盘写的IO量大 4）内存不足时频繁使用虚拟内存

    4）软件下载与流媒体服务：1）网络带宽瓶颈 2）存储系统带宽瓶颈(读)

六、性能分析工具

    1、vmstat是一个很全面的性能分析工具，可以观察到系统的进程状态、内存使用、虚拟内存使用、磁盘的IO、中断、上下问切换、CPU使用等；

?Procs

–r:

运行的和等待(CPU时间片)运行的进程数，这个值也可以判断是否需要增加CPU(长期大于1)

–b:

处于不可中断状态的进程数，常见的情况是由IO引起的

?Memory

–swpd: 切换到交换内存上的内存(默认以KB为单位)

?如果 swpd 的值不为0，或者还比较大，比如超过100M了，但是 si, so 的值长期为 0，这种情况我们可以不用担心，不会影响系统性能。

–free: 空闲的物理内存

–buff: 作为buffer cache的内存，对块设备的读写进行缓冲

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

如果 cache 的值大的时候，说明cache住的文件数多，如果频繁访问到的文件都能被cache住，那么磁盘的读IO bi 会非常小

?Swap

–si: 交换内存使用，由磁盘调入内存

–so: 交换内存使用，由内存调入磁盘

内存够用的时候，这2个值都是0，如果这2个值长期大于0时，系统性能会受到影响。磁盘IO和CPU资源都会被消耗。

我发现有些朋友看到空闲内存(free)很少或接近于0时，就认为内存不够用了，实际上不能光看这一点的，还要结合si,so，如果free很少，但是si,so也很少(大多时候是0)，那么不用担心，系统性能这时不会受到影响的。

?Io

–bi: 从块设备读入的数据总量(读磁盘) (KB/s)，

–bo: 写入到块设备的数据总理(写磁盘) (KB/s)

随机磁盘读写的时候，这2个 值越大（如超出1M），能看到CPU在IO等待的值也会越大

?System

–in: 每秒产生的中断次数

–cs: 每秒产生的上下文切换次数

上面这2个值越大，会看到由内核消耗的CPU时间会越多

?Cpu

–us: 用户进程消耗的CPU时间百分比

?us 的值比较高时，说明用户进程消耗的CPU时间多，但是如果长期超过50% 的使用，那么我们就该考虑优化程序算法或者进行加速了(比如 PHP/Perl)

–sy: 内核进程消耗的CPU时间百分比

?sy 的值高时，说明系统内核消耗的CPU资源多，这并不是良性的表现，我们应该检查原因。

–wa: IO等待消耗的CPU时间百分比

?wa 的值高时，说明IO等待比较严重，这可能是由于磁盘大量作随机访问造成，也有可能是磁盘的带宽出现瓶颈(块操作)。

–id: CPU处在空闲状态时间百分比

?情景分析

这个vmstat的输出那些信息值得关注？

–Procs r: 运行的进程比较多，系统很繁忙

–Io bo: 磁盘写的数据量稍大，如果是大文件的写，10M以内基本不用担心，如果是小文件写2M以内基本正常

–Cpu us: 持续大于50，服务高峰期可以接受

–Cpu wa: 稍微有些高

–Cpu id:持续小于50，服务高峰期可以接受

    2、TOP

这个命令可以查看系统中运行的进程的状况，CPU使用状况，系统负载，内存使用等。它是检查系统进程运行状况最方便的工具了，它默认显示部分活动的进程，并且按照进程使用CPU的多少排序。它可以显示全部CPU的使用状况，也可以显示每个进程都运行在那个CPU上面。

我习惯使用这个命令查看那些进程或者那类进程占用CPU和内存资源最多，以此迅速定位存在性能问题的进程，以及运行异常的进程.

?Top命令的输出1 (CentOS 3.3)

?Top命令的输出2 (CentOS 3.3)

?用 top 看到的内存的说明(Mem的第2行)

–actv

active 活跃的内存页，正在映射给进程使用

–in_d

inactive_dirty 非活跃的内存页，并且内存数据被修改，需要写回磁盘

–in_c

inactive_clean 非活跃的内存页，干净的数据，可以被重新分配使用

actv, in_d, in_c 是 VM 中对内存的管理组织形式，buffer是块设备读写缓冲，cache是文件系统缓存

?用 top 看到的进程所处的几种状态(STAT列)。

–D 不可中断休眠，通常是 IO 操作所处的状态

–R 正在执行的或者处在等待执行的进程队列中

–S 休眠中

–T 暂停刮起的（比如Ctrl+Z），也可能是被 strace 命令调用中的状态

–Z 僵尸进程，进程执行完成，但由于其父进程没有销毁该进程，而被init进程接管进行销毁。

–W 没有使用物理内存，所占用的物理内存被切换到交换内存

–< 高优先级的进程

–N 低优先级

?情景分析

前面两次top的输出那些信息值得关注？

–图1)

?Load average: 系统负载有降低的趋势，但仍然较高

?Running: 有3个进程正在运行，正常，因为系统有4颗CPU

?Cpu user: 接近200%了，有些大，服务高峰时可以接受

?Cpu idle: 小于200%了，需要注意

–图2)

–Cpu iowait:接近200%了，很大

3)free

free命令显示系统内存的使用状况（物理内存和交换内存）

通过这个命令我们可以看到系统进程实际使用的物理内存，buffer和cache使用的物理内存

?free命令输出的第二行(Mem)

这行分别显示了物理内存的总量(total)、已使用的(used)、空闲的(free)、共享的(shared)、buffer、cache的内存。

?free命令输出的第三行(-/+ buffers/cache)

这行最容易让人迷惑。

它显示的第一个值（used这一列）是这样得来的：

Mem行used列 - Mem行buffers列 - Mem行cached列

它显示的第二个值（free这一列）是这样得来的：

Mem行free列 + Mem行buffers列 + Mem行cached列

?free命令输出的第四行(Swap)

这行显示交换内存的总量、已使用量、空闲量

通常 buffer 和 cache 可以使用的内存空间越大，系统 IO 和文件系统访问的性能越好

4)uptime

我一般以15分钟负载的值来评估系统的健康度，以10为这个值的临界点，如果系统负载持续高于10，通常是存在某个资源长期紧张的原因，我们需要重视，并且得开始着手解决这个问题了。

如果偶尔高于10，应该开始留意它出现的频度，这往往是前面一种状况的先兆。

5)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

6)Iozone

IO和文件系统性能测试的工具，我也习惯用它作存储系统的性能分析。

7)Strace

如果我们知道一个程序执行效率很差，需要分析这个程序执行时的某个阶段或者某个系统调用的性能状况，可以使用 strace 命令。

六、优化实例

1）动态内容为主的网站

?该网站系统结构说明

–1台Dell2650服务器, 单颗Xeon 3.0G CPU，1G内存，2块72G SCSI磁盘

–操作系统 CentOS 3.3

–应用基于LAMP架构，所有服务都在一台服务器上

?初期性能问题及处理

–表现：早晨和下午访问高峰时，服务器频繁宕机，重启后的一段时间内能正常服务，过一会以后又变的响应缓慢，然后又宕机。

–检查：发现宕机前系统负载高，Apache httpd.conf 配置最大用户数为1024

–处理：修改 httpd.conf 配置文件，降到最大 512 个用户数，仍然频繁宕机，又降到 256 个用户数，系统不宕机了，但是负载很高，站点访问极慢

?初次优化

深入分析系统资源使用情况(vmstat,top,ps)

–结论：CPU资源时常耗尽，因此造成响应缓慢或者长时间没有响应，主要是用户进程消耗资源严重。

–原因：PHP程序没有使用代码加速，网站首页是个PHP程序，每次用户访问都要多次查询数据库，其他程序也没有Cache机制，数据库查询负荷过高。

–处理：安装配置turck-mmcache代码加速器，改写网站首页以及部分频繁访问的程序增加cache机制，减少数据库访问。

?第二次优化

一段时间后，系统又开始不稳定，访问高峰时站点无法正常访问

–分析系统资源使用状况，发现仍然是CPU耗尽后引起问题，但这次系统IO等待消耗的CPU资源比较大。

–原因：上次解决了CPU资源容易耗尽的问题，目前网站访问量增加了，apache进程数时常达到256个，导致内存使用殆尽，频繁使用交换内存，最终仍然导致CPU资源耗尽

–处理：把Apache配置中的 KeepAlive 特性关闭，进程数大量减少，基本保持在80个进程以内，还是会使用交换内存，但是服务正常了。

?第三次优化

一段时间后，系统又开始不稳定，访问高峰时站点无法正常访问

–分析发现还是CPU资源耗尽导致的原因。

–原因：程序频繁访问数据库，大量的SQL语句中有 where, order by 等子句，而大量的表没有建索引，导致MySQL数据库负荷过高，消耗CPU资源过高。

–处理：优化程序中的SQL语句，where和order by子句上的字段建索引，程序增加Cache机制，再次使服务恢复正常。

?第四次优化

一段时间后，系统又开始不稳定，访问高峰时站点无法正常访问

–分析系统资源使用状况，发现还是CPU耗尽造成的

–原因：数据库查询过多，大部分都是复杂查询，时常需要遍历全表

–处理：优化程序中的SQL语句，增加where子句上的匹配条件，减少遍历全部的查询。

?网站结构优化

–鉴于程序的优化空间越来越小，避免以后仍然出现问题，增加了一台专用数据库服务器

–在后来的使用过程中，又陆续增加了1台Web前端服务器，和一台只用于读的MySQL数据库服务器

2）动态内容+Cache为主的网站

?该网站系统结构说明

–多台Web前端服务器, 配置都为单颗Xeon 3.0G CPU，4G内存，2块73G SCSI磁盘

–操作系统 CentOS 3.3

–多台MySQL数据库服务器

–基于PHP开发的应用

?该应用的特点

–大量内容基于数据库，需要频繁访问数据库，并且数据更新很快

–采用页面cache机制缓解数据库压力，但页面cache只有5分钟有效期，需要频繁生成新的cache

–Cache以文件形式存在磁盘上，都是小文件，最小不到1k，最大不超过128k

?问题描述

–访问高峰期时Web前端负载比较高，时常超过10

–访问高峰期时Web前端响应很慢

?性能分析

–负载比较高，时常会超过10，CPU Idel经常会小于30%，有时Idel为0，CPU io wait 很大，经常超过30%，磁盘读每秒不超过100k，磁盘写每秒1.5M左右，磁盘tps超过100

–访问高峰期时内存也有部分空闲，用于buffer和cache的内存基本占总内存60%以上，没有使用交换内存

?原因分析

–分析该应用的特点后发现，访问高峰期时，要频繁生成新的cache文件，或者更新以及过期的cache文件，cache文件目录为256x256的哈希结构，因此读写文件时磁盘随机寻址非常频繁

–该应用磁盘写远大于磁盘读的原因是系统cache命中率高，大量文件读过一次就cache住了，因此读的开销很小

–写磁盘的量并不算很大，平均每秒1.5M，但都是随机写，因此写磁盘速度会稍微慢，也因此会消耗大量CPU时间

–对比访问高峰期和访问量小时候的系统状态，磁盘写的tps提高了1倍以上，CPU io wait提高了3倍以上，因此认为主要性能瓶颈在磁盘写上

?优化办法

–减少磁盘写的次数，cache文件先写在内存中，超过一定访问次数时才写回磁盘，但由于要修改应用程序，因此执行难度大

–减少磁盘随机写的次数，前端不使用255x255的哈希目录，而是把多个cache文件写在一个大的cache文件中，并且只作追加写，这样就能把随机写变成了顺序写，cache过期后，整个大的cache文件可以一次删除。但由于要修改应用，因此执行难度大

上面2个办法结合使用，听上去性能会更好，但是执行难度更大

–使用tmpfs作cache磁盘(ramdisk也可以)，这样写都在访问内存，没有磁盘IO消耗，缺点是cache的空间不会很大，不能超过2G(该服务器是4G内存)，但是不用修改应用程序，执行容易：

?Mount –bind /dev/shm /var/www/cache

?写一个清cache的脚本程序，配置在cron中，30分钟执行一次，检查/dev/shm的使用率超过70%时，使用find命令找出太旧的cache文件删除掉

最终采用了这个办法，高峰期系统负载小于5