1、系统性能分析和优化,童剑 2006/03/21 msn: ,我们将会讨论下列7个话题,性能分析的目的 性能分析相关的人 性能相关的各个环节 系统使用和优化的原则 典型应用对系统资源使用的特点 常见的性能分析工具介绍 性能分析及优化的案例,开始第1个话题,性能分析的目的 性能分析相关的人 性能相关的各个环节 系统使用和优化的原则 典型应用对系统资源使用的特点 常见的性能分析工具介绍 性能分析及优化的案例,性能分析的目的,找出系统性能瓶颈 硬件瓶颈 软件瓶颈 提供性能优化方案 升级硬件 改进系统结构 达到合理的硬件和软件配置 使系统资源使用达到平衡,性能分析的目的,但遗憾的是解决一个性能瓶颈，往往
2、又会出现另外的瓶颈或者其他问题，所以性能优化更加切实的目标是做到在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡。系统运行良好的时候恰恰也是各项资源达到了一个平衡体，任何一项资源的过渡使用都会造成平衡体系破坏，从而造成系统负载极高或者响应迟缓。比如CPU过渡使用会造成大量进程等待CPU资源，系统响应变慢，等待会造成进程数增加，进程增加又会造成内存使用增加，内存耗尽又会造成虚拟内存使用，使用虚拟内存又会造成磁盘IO增加和CPU开销增加（用于进程切换、缺页处理的CPU开销）,开始第2个话题,性能分析的目的 性能分析相关的人 性能相关的各个环节 系统使用和优化的原则 典型应用对系统资源使用的
3、特点 常见的性能分析工具介绍 性能分析及优化的案例,性能分析相关的人,系统管理员 大型应用的系统结构设计人员 软件开发人员,性能分析相关的人,系统管理员 掌握系统运行状况(负载) 掌握系统资源使用情况(硬件) 掌握应用程序对资源的使用情况(应用程序执行效率，反馈给应用开发人员) 有针对性的开展服务器性能优化(硬件、软件、软件配置),性能分析相关的人,系统架构设计人员 了解程序执行效率 了解系统架构中的性能瓶颈，优化系统结构 设计更好的应用系统架构,性能分析相关的人,软件开发人员 了解程序执行效率 改进程序逻辑、改进性能,开始第3个话题,性能分析的目的 性能分析相关的人 性能相关的各个环节 系统
4、使用和优化的原则 典型应用对系统资源使用的特点 常见的性能分析工具介绍 性能分析及优化的案例,性能相关的各个环节,硬件资源 操作系统 服务器软件 开发平台/中间件软件/框架软件 应用程序,性能相关的-硬件资源,CPU 内存 存储系统 带宽,性能相关的-硬件资源,CPU 是否使用SMP 单颗CPU的性能对依赖CPU的某些应用的影响很严重，比如数据库的查询处理,性能相关的-硬件资源,内存 物理内存物理内存不够时会使用交换内存 交换内存使用交换内存会带来磁盘IO和CPU的开销增加,性能相关的-硬件资源,存储系统 SCSI磁盘 ATA/SATA磁盘 RAID磁盘阵列(RAID0, RAID1, RAI
5、D5, RAID0+1) 一些经验小文件读写的性能瓶颈是磁盘的寻址（随机读写性能更差），评估的标准是tps大文件读写的性能瓶颈是带宽，评估的标准是持续的读写速度Linux可以利用空闲内存作文件系统访问的cache，因此系统内存越大存储系统的性能也越好,性能相关的-硬件资源,带宽 网络带宽 SCSI总线带宽 大文件访问时SCSI的带宽瓶颈 系统总线带宽,性能相关的-操作系统,SMP性能 VM性能 IO性能(存储设备、网络设备、异步IO) 文件系统性能(大文件优化、小文件优化、写优化、读优化、网络文件系统) 多线程性能,开始第4个话题,性能分析的目的 性能分析相关的人 性能相关的各个环节 系统使用
6、和优化的原则 典型应用对系统资源使用的特点 常见的性能分析工具介绍 性能分析及优化的案例,系统使用和优化的原则,对资源的使用状况作长期的监控和数据收集 Snmp+MRTG Sar 程序的优化和系统结构的优化比硬件的性能优化更有效 避免不受限制的使用系统资源 设置各项服务对资源的使用限额，如Apache, MySQL,PHP等,系统使用和优化的原则,始终保留一定量的空闲资源 多少合适？根据应用的特点，比如是否有突发性使用增长？ 日常情况下，保留至少 60% 的系统资源，以应付突发使用增长。 日常情况下，资源使用率达到 80% 时，你必须有所行动了，尤其是web应用。 系统硬件达到合理的配置（以适
7、合应用的特点为依据，资源消耗均衡为目标） 系统性能的水桶理论,系统使用和优化的原则,应用软件对资源的使用要均衡（理想目标） 怎么样就算是均衡了？我也在摸索中 理想状况为：CPU消耗到50%的时候，磁盘的带宽也到50%，磁盘的tps也到50%，内存使用也到50%(除去可以提供给cache的内存),开始第5个话题,性能分析的目的 性能分析相关的人 性能相关的各个环节 系统使用和优化的原则 典型应用对系统资源使用的特点 常见的性能分析工具介绍 性能分析及优化的案例,典型应用对系统资源使用的特点,声明这部分内容主要是本人在网站工作多年的一些实践经验积累， 所以这些经验并不完全适用于其他的应用环境。在我
8、的经验中，大多数的硬件性能问题主要和CPU、磁盘、内存相关， 还没有遇到因为开发语言的运行效率对整个应用的性能造成影响，而应用程序设计的缺陷和数据库查询的滥用反倒是最最常见的性能问题。需要注意的是，大多数情况下，虽然性能瓶颈的起因是程序性能差或者是内存不足或者是磁盘瓶颈等各种原因，但最终表现出的结果就是CPU耗尽，系统负载极高，响应迟缓，甚至暂时失去响应，因此我们观察服务器状况时，最先看的就是系统负载和CPU空闲度。,典型应用对系统资源使用的特点,动态内容为主的Web应用 静态内容为主的Web应用 (如Squid Cache) 数据库应用 软件下载 流媒体服务,典型应用对系统资源使用的特点,动
9、态内容为主的Web应用 频繁执行程序，如 Perl, PHP, Java 等，消耗CPU严重 提供并发用户访问，因此系统进程数多，消耗内存多，当内存不足时，使用交换内存也会增加CPU的开销 磁盘的写IO比较频繁（主要为随机写），比如生成cache文件，更新session文件等。 内存充足时读取的内容可以被cache住，cache的命中率和文件更新的频繁程度成反比，磁盘的读IO相对较小,典型应用对系统资源使用的特点,静态内容为主的Web应用 (如Squid Cache) 网络带宽瓶颈 小文件的随机读取频繁，内存充足时可以缓解磁盘随机读的压力 系统内存不足时磁盘IO量会比较大（读、写、交换内存），
10、因此增加CPU的开销,典型应用对系统资源使用的特点,数据库应用 数据库查询语句复杂，大量的 where 子句，order by, group by 排序等，CPU容易出现瓶颈 表太大时，查询遍历全表造成磁盘读的IO量大，容易出现读IO等待的情况 数据更新量大或者更新频繁时，造成磁盘写的IO量大 内存不足时频繁使用交换内存,典型应用对系统资源使用的特点,软件下载 网络带宽瓶颈 存储系统带宽瓶颈(读) 流媒体服务 网络带宽瓶颈 存储系统带宽瓶颈(读),开始第6个话题,性能分析的目的 性能分析相关的人 性能相关的各个环节 系统使用和优化的原则 典型应用对系统资源使用的特点 常见的性能分析工具介绍 性
11、能分析及优化的案例,常见的性能分析工具介绍,Vmstat Top Free Uptime sysstat 工具包 Iozone Strace希望看完以上工具的使用说明，让你能够知道如何判断系统瓶颈在那里、内存是否够用、CPU是否够用、磁盘IO是否够用、网络和磁盘带宽是否够用等问题。,工具介绍-vmstat,vmstat是一个很全面的性能分析工具，可以观察到系统的进程状态、内存使用、虚拟内存使用、磁盘的IO、中断、上下问切换、CPU使用等。系统性能分析工具中，我使用最多的是这个，除了 sysstat 工具包外，这个工具能查看的系统资源最多。对于 Linux 的性能分析，100%理解 vmstat
12、 输出内容的含义，那你对系统性能分析的能力就算是基本掌握了。我这里主要说明一下这个命令显示出的部分数据代表的含义，和它反映出系统相关资源的状况。输出内容共有 6 类，分别说明如下。,工具介绍-vmstat,Vmstat的输出格式如下(CentOS 3.3),工具介绍-vmstat,Procs r:运行的和等待(CPU时间片)运行的进程数，这个值也可以判断是否需要增加CPU(长期大于1) b:处于不可中断状态的进程数，常见的情况是由IO引起的,工具介绍-vmstat,Memory swpd: 切换到交换内存上的内存(默认以KB为单位) 如果 swpd 的值不为0，或者还比较大，比如超过100M了
13、，但是 si, so 的值长期为 0，这种情况我们可以不用担心，不会影响系统性能。 free: 空闲的物理内存 buff: 作为buffer cache的内存，对块设备的读写进行缓冲 cache: 作为page cache的内存, 文件系统的cache 如果 cache 的值大的时候，说明cache住的文件数多，如果频繁访问到的文件都能被cache住，那么磁盘的读IO bi 会非常小。,工具介绍-vmstat,Swap si: 交换内存使用，由磁盘调入内存 so: 交换内存使用，由内存调入磁盘 内存够用的时候，这2个值都是0，如果这2个值长期大于0时，系统性能会受到影响。磁盘IO和CPU资源都
14、会被消耗。 我发现有些朋友看到空闲内存(free)很少或接近于0时，就认为内存不够用了，实际上不能光看这一点的，还要结合si,so，如果free很少，但是si,so也很少(大多时候是0)，那么不用担心，系统性能这时不会受到影响的。,工具介绍-vmstat,Io bi: 从块设备读入的数据总量(读磁盘) (KB/s)， bo: 写入到块设备的数据总理(写磁盘) (KB/s) 随机磁盘读写的时候，这2个 值越大（如超出1M），能看到CPU在IO等待的值也会越大,工具介绍-vmstat,System in: 每秒产生的中断次数 cs: 每秒产生的上下文切换次数 上面这2个值越大，会看到由内核消耗的C
15、PU时间会越多,工具介绍-vmstat,Cpu us: 用户进程消耗的CPU时间百分比 us 的值比较高时，说明用户进程消耗的CPU时间多，但是如果长期超过50% 的使用，那么我们就该考虑优化程序算法或者进行加速了(比如 PHP/Perl) sy: 内核进程消耗的CPU时间百分比 sy 的值高时，说明系统内核消耗的CPU资源多，这并不是良性的表现，我们应该检查原因。 wa: IO等待消耗的CPU时间百分比 wa 的值高时，说明IO等待比较严重，这可能是由于磁盘大量作随机访问造成，也有可能是磁盘的带宽出现瓶颈(块操作)。 id: CPU处在空闲状态时间百分比,工具介绍-vmstat,情景分析这个
16、vmstat的输出那些信息值得关注？ Procs r: 运行的进程比较多，系统很繁忙 Io bo: 磁盘写的数据量稍大，如果是大文件的写，10M以内基本不用担心，如果是小文件写2M以内基本正常 Cpu us: 持续大于50，服务高峰期可以接受 Cpu wa: 稍微有些高 Cpu id:持续小于50，服务高峰期可以接受,工具介绍-top,这个命令可以查看系统中运行的进程的状况，CPU使用状况，系统负载，内存使用等。它是检查系统进程运行状况最方便的工具了，它默认显示部分活动的进程，并且按照进程使用CPU的多少排序。它可以显示全部CPU的使用状况，也可以显示每个进程都运行在那个CPU上面。我习惯使用
17、这个命令查看那些进程或者那类进程占用CPU和内存资源最多，以此迅速定位存在性能问题的进程，以及运行异常的进程。,工具介绍-top,Top命令的输出1 (CentOS 3.3),工具介绍-top,Top命令的输出2 (CentOS 3.3),工具介绍-top,用 top 看到的内存的说明(Mem的第2行) actv active 活跃的内存页，正在映射给进程使用 in_dinactive_dirty 非活跃的内存页，并且内存数据被修改，需要写回磁盘 in_cinactive_clean 非活跃的内存页，干净的数据，可以被重新分配使用,工具介绍-top,问题？in_d 和 in_c 以及 cach
18、e, buffer 的内存有何不同？我的理解：actv, in_d, in_c 是 VM 中对内存的管理组织形式，buffer是块设备读写缓冲，cache是文件系统缓存,工具介绍-top,用 top 看到的进程所处的几种状态(STAT列)。 D 不可中断休眠，通常是 IO 操作所处的状态 R 正在执行的或者处在等待执行的进程队列中 S 休眠中 T 暂停刮起的（比如Ctrl+Z），也可能是被 strace 命令调用中的状态 Z 僵尸进程，进程执行完成，但由于其父进程没有销毁该进程，而被init进程接管进行销毁。 W 没有使用物理内存，所占用的物理内存被切换到交换内存 高优先级的进程 N 低优先级
19、有时候一个进程会有多个状态的标志，比如SWN，SW,工具介绍-top,情景分析前面两次top的输出那些信息值得关注？ 图1) Load average: 系统负载有降低的趋势，但仍然较高 Running: 有3个进程正在运行，正常，因为系统有4颗CPU Cpu user: 接近200%了，有些大，服务高峰时可以接受 Cpu idle: 小于200%了，需要注意 图2) Cpu iowait:接近200%了，很大,工具介绍-free,free命令显示系统内存的使用状况（物理内存和交换内存） 通过这个命令我们可以看到系统进程实际使用的物理内存，buffer和cache使用的物理内存,工具介绍-fr
20、ee,free命令输出的第二行(Mem)这行分别显示了物理内存的总量(total)、已使用的(used)、空闲的(free)、共享的(shared)、buffer、cache的内存。,工具介绍-free,free命令输出的第三行(-/+ buffers/cache)这行最容易让人迷惑。它显示的第一个值（used这一列）是这样得来的：Mem行used列 - Mem行buffers列 - Mem行cached列它显示的第二个值（free这一列）是这样得来的：Mem行free列 + Mem行buffers列 + Mem行cached列,工具介绍-free,free命令输出的第四行(Swap)这行显示
21、交换内存的总量、已使用量、空闲量通常 buffer 和 cache 可以使用的内存空间越大，系统 IO 和 文件系统访问的性能越好。,工具介绍-uptime,最简便的查看系统负载的工具，系统负载越小，系统运行状况越好，对于系统负载处在什么范围内比较合适，我想是没有定论的，我介绍一下我的习惯。我一般以15分钟负载的值来评估系统的健康度，以10为这个值的临界点，如果系统负载持续高于10，通常是存在某个资源长期紧张的原因，我们需要重视，并且得开始着手解决这个问题了。如果偶尔高于10，应该开始留意它出现的频度，这往往是前面一种状况的先兆。,工具介绍- sysstat工具包,这个工具包提供了著名的 sa
22、r 命令，还有非常实用的 iostat, mpstat, sa1, sa2 等命令。 这几个命令可实现前面提及工具大多数的功能，除此之外，还能查看系统的网络带宽状况、每块磁盘使用状况、每个磁盘分区的使用状况等。,工具介绍- sysstat工具包,sa1, sa2 这2个命令以配置在cron中定期执行，把系统当时的运行状况信息保存在磁盘上，每日存在一个文件中，因为有这个功能，因此 sar 工具不单是一个性能分析的工具，这2个命令的使用说明如下：sa1 配置在cron中可以实现系统状态收集，比如10分钟运行一次sa2 配置在cron中可以实现每日状态的汇总报告你可以在系统crontab中添加如下配
23、置：*/10 * * * * root /usr/lib/sa/sa1 1 153 23 * * * root /usr/lib/sa/sa2 -A,工具介绍-其他,IozoneIO和文件系统性能测试的工具，我也习惯用它作存储系统的性能分析。 Strace如果我们知道一个程序执行效率很差，需要分析这个程序执行时的某个阶段或者某个系统调用的性能状况，可以使用 strace 命令。 其他,开始第7个话题,性能分析的目的 性能分析相关的人 性能相关的各个环节 系统使用和优化的原则 典型应用对系统资源使用的特点 常见的性能分析工具介绍 性能分析及优化的案例,性能分析及优化的案例,动态内容为主的网站 动
24、态内容+Cache为主的网站,动态内容为主的网站,该网站系统结构说明 1台Dell2650服务器, 单颗Xeon 3.0G CPU，1G内存，2块72G SCSI磁盘 操作系统 CentOS 3.3 应用基于LAMP架构，所有服务都在一台服务器上,动态内容为主的网站,分析和优化的过程 初期性能问题及处理 第二次优化 第三次优化 第四次优化 网站结构优化,动态内容为主的网站,初期性能问题及处理 表现：早晨和下午访问高峰时，服务器频繁宕机，重启后的一段时间内能正常服务，过一会以后又变的响应缓慢，然后又宕机。 检查：发现宕机前系统负载高，Apache httpd.conf 配置最大用户数为1024
25、处理：修改 httpd.conf 配置文件，降到最大 512 个用户数，仍然频繁宕机，又降到 256 个用户数，系统不宕机了，但是负载很高，站点访问极慢,动态内容为主的网站,初次优化深入分析系统资源使用情况(vmstat,top,ps) 结论：CPU资源时常耗尽，因此造成响应缓慢或者长时间没有响应，主要是用户进程消耗资源严重。 原因：PHP程序没有使用代码加速，网站首页是个PHP程序，每次用户访问都要多次查询数据库，其他程序也没有Cache机制，数据库查询负荷过高。 处理：安装配置turck-mmcache代码加速器，改写网站首页以及部分频繁访问的程序增加cache机制，减少数据库访问。,动态
26、内容为主的网站,第二次优化一段时间后，系统又开始不稳定，访问高峰时站点无法正常访问 分析系统资源使用状况，发现仍然是CPU耗尽后引起问题，但这次系统IO等待消耗的CPU资源比较大。 原因：上次解决了CPU资源容易耗尽的问题，目前网站访问量增加了，apache进程数时常达到256个，导致内存使用殆尽，频繁使用交换内存，最终仍然导致CPU资源耗尽 处理：把Apache配置中的 KeepAlive 特性关闭，进程数大量减少，基本保持在80个进程以内，还是会使用交换内存，但是服务正常了。,动态内容为主的网站,第三次优化一段时间后，系统又开始不稳定，访问高峰时站点无法正常访问 分析发现还是CPU资源耗尽
27、导致的原因。 原因：程序频繁访问数据库，大量的SQL语句中有 where, order by 等子句，而大量的表没有建索引，导致MySQL数据库负荷过高，消耗CPU资源过高。 处理：优化程序中的SQL语句，where和order by子句上的字段建索引，程序增加Cache机制，再次使服务恢复正常。,动态内容为主的网站,第四次优化一段时间后，系统又开始不稳定，访问高峰时站点无法正常访问 分析系统资源使用状况，发现还是CPU耗尽造成的 原因：数据库查询过多，大部分都是复杂查询，时常需要遍历全表 处理：优化程序中的SQL语句，增加where子句上的匹配条件，减少遍历全部的查询。,动态内容为主的网站,
28、网站结构优化 鉴于程序的优化空间越来越小，避免以后仍然出现问题，增加了一台专用数据库服务器 在后来的使用过程中，又陆续增加了1台Web前端服务器，和一台只用于读的MySQL数据库服务器,动态内容+Cache为主的网站,该网站系统结构说明 多台Web前端服务器, 配置都为单颗Xeon 3.0G CPU，4G内存，2块73G SCSI磁盘 操作系统 CentOS 3.3 多台MySQL数据库服务器 基于PHP开发的应用,动态内容+Cache为主的网站,该应用的特点 大量内容基于数据库，需要频繁访问数据库，并且数据更新很快 采用页面cache机制缓解数据库压力，但页面cache只有5分钟有效期，需要
29、频繁生成新的cache Cache以文件形式存在磁盘上，都是小文件，最小不到1k，最大不超过128k,动态内容+Cache为主的网站,问题描述 访问高峰期时Web前端负载比较高，时常超过10 访问高峰期时Web前端响应很慢 性能分析 负载比较高，时常会超过10，CPU Idel经常会小于30%，有时Idel为0，CPU io wait 很大，经常超过30%，磁盘读每秒不超过100k，磁盘写每秒1.5M左右，磁盘tps超过100 访问高峰期时内存也有部分空闲，用于buffer和cache的内存基本占总内存60%以上，没有使用交换内存,动态内容+Cache为主的网站,原因分析 分析该应用的特点后发
30、现，访问高峰期时，要频繁生成新的cache文件，或者更新以及过期的cache文件，cache文件目录为256x256的哈希结构，因此读写文件时磁盘随机寻址非常频繁 该应用磁盘写远大于磁盘读的原因是系统cache命中率高，大量文件读过一次就cache住了，因此读的开销很小 写磁盘的量并不算很大，平均每秒1.5M，但都是随机写，因此写磁盘速度会稍微慢，也因此会消耗大量CPU时间 对比访问高峰期和访问量小时候的系统状态，磁盘写的tps提高了1倍以上，CPU io wait提高了3倍以上，因此认为主要性能瓶颈在磁盘写上,动态内容+Cache为主的网站,优化办法 减少磁盘写的次数，cache文件先写在内
31、存中，超过一定访问次数时才写回磁盘，但由于要修改应用程序，因此执行难度大 减少磁盘随机写的次数，前端不使用255x255的哈希目录，而是把多个cache文件写在一个大的cache文件中，并且只作追加写，这样就能把随机写变成了顺序写，cache过期后，整个大的cache文件可以一次删除。但由于要修改应用，因此执行难度大 上面2个办法结合使用，听上去性能会更好，但是执行难度更大,动态内容+Cache为主的网站,优化办法 使用tmpfs作cache磁盘(ramdisk也可以)，这样写都在访问内存，没有磁盘IO消耗，缺点是cache的空间不会很大，不能超过2G(该服务器是4G内存)，但是不用修改应用程序，执行容易： Mount bind /dev/shm /var/www/cache 写一个清cache的脚本程序，配置在cron中，30分钟执行一次，检查/dev/shm的使用率超过70%时，使用find命令找出太旧的cache文件删除掉最终采用了这个办法，高峰期系统负载小于5,相关的参考资料,Red Hat Enterprise Linux Introduction to System Administration http:/ Sysstat 工具集http:/ 其他查看系统的 man 手册,结束啦！,谢谢参与！,
