页: 前页 1 2 3 ...61 62 63 64 65 66 67 68 69 后页

系统性能分析和优化讲义

2009年2月9日

系统性能分析和优化

前言

很高兴能有这样的机会,把我自己多年工作中对服务器硬件、软件方面的性能分析的经验和体会,以及性能优化的经验和各位朋友做一次分享。

这份ppt的内容组织大致是这样的,通过对系统中和性能相关的各个环节的介绍,使大家知道出现性能问题时可以从那些方面入手去查,而分析典型应用对系统资源使用的特点,让大家对应用和系统资源的依赖有了更直观的认识,然后我会介绍常见的分析及监控系统资源时使用的工具,这个环节应该是最主要的,最后我会举一个实际发生过的系统性能瓶颈分析和优化的案例,作为一个实践和总结。

 

本文涉及的内容基于Gnu/Linux系统平台,但关于性能优化分析和优化的思路也能适用于其他系统平台。

我们将会讨论下列7个话题

+性能分析的目的

+性能分析相关的人

+性能相关的各个环节

+系统使用和优化的原则

+典型应用对系统资源使用的特点

+常见的性能分析工具介绍

+性能分析及优化的案例

开始第1个话题

性能分析的目的

+性能分析相关的人

+性能相关的各个环节

+系统使用和优化的原则

+典型应用对系统资源使用的特点

+常见的性能分析工具介绍

+性能分析及优化的案例

性能分析的目的

+找出系统性能瓶颈

-硬件瓶颈

-软件瓶颈

+提供性能优化方案

-升级硬件

-改进系统结构

+达到合理的硬件和软件配置

+使系统资源使用达到平衡

性能分析的目的

+但遗憾的是

解决一个性能瓶颈,往往又会出现另外的瓶颈或者其他问题,所以性能优化更加切实的目标是做到在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡。

系统运行良好的时候恰恰也是各项资源达到了一个平衡体,任何一项资源的过渡使用都会造成平衡体系破坏,从而造成系统负载极高或者响应迟缓。比如CPU过渡使用会造成大量进程等待CPU资源,系统响应变慢,等待会造成进程数增加,进程增加又会造成内存使用增加,内存耗尽又会造成虚拟内存使用,使用虚拟内存又会造成磁盘IO增加和CPU开销增加(用于进程切换、缺页处理的CPU开销)

开始第2个话题

+性能分析的目的

性能分析相关的人

+性能相关的各个环节

+系统使用和优化的原则

+典型应用对系统资源使用的特点

+常见的性能分析工具介绍

+性能分析及优化的案例

性能分析相关的人

+系统管理员

+大型应用的系统结构设计人员

+软件开发人员

性能分析相关的人

+系统管理员

掌握系统运行状况(负载)

掌握系统资源使用情况(硬件)

掌握应用程序对资源的使用情况(应用程序执行效率,反馈给应用开发人员)

有针对性的开展服务器性能优化(硬件、软件、软件配置)

性能分析相关的人

+系统架构设计人员

 了解程序执行效率

 了解系统架构中的性能瓶颈,优化系统结构

 设计更好的应用系统架构

性能分析相关的人

+软件开发人员

了解程序执行效率

改进程序逻辑、改进性能

开始第3个话题

+性能分析的目的

+性能分析相关的人

性能相关的各个环节

+系统使用和优化的原则

+典型应用对系统资源使用的特点

+常见的性能分析工具介绍

+性能分析及优化的案例

性能相关的各个环节

+硬件资源

+操作系统

+服务器软件

+开发平台/中间件软件/框架软件

+应用程序

性能相关的-硬件资源

+CPU

+内存

+存储系统

+带宽

性能相关的-硬件资源

+CPU

 是否使用SMP

 单颗CPU 的性能对依赖CPU 的某些应用的影响很严重,比如数据库的查询处理

性能相关的-硬件资源

+内存

物理内存

物理内存不够时会使用交换内存

 交换内存

使用交换内存会带来磁盘IOCPU的开销增加

性能相关的-硬件资源

+存储系统

– SCSI磁盘

– ATA/SATA磁盘

– RAID磁盘阵列(RAID0, RAID1, RAID5, RAID0+1)

– 一些经验

 小文件读写的性能瓶颈是磁盘的寻址(随机读写性能更差),评估的标准是tps

 大文件读写的性能瓶颈是带宽,评估的标准是持续的读写速度

 Linux可以利用空闲内存作文件系统访问的cache因此系统内存越大存储系统的性能也越好

性能相关的-硬件资源

+带宽

 网络带宽

SCSI 总线带宽

+ 大文件访问时SCSI 的带宽瓶颈

 系统总线带宽

性能相关的-操作系统

+SMP性能

+VM性能

+IO性能(存储设备、网络设备、异步IO)

+文件系统性能(大文件优化、小文件优化、写优化、读优化、网络文件系统)

+多线程性能

开始第4个话题

+性能分析的目的

+性能分析相关的人

+性能相关的各个环节

系统使用和优化的原则

+典型应用对系统资源使用的特点

+常见的性能分析工具介绍

+性能分析及优化的案例

系统使用和优化的原则

+对资源的使用状况作长期的监控和数据收集

-Snmp+MRTG

-Sar

+程序的优化和系统结构的优化比硬件的性能优化更有效

+避免不受限制的使用系统资源

-设置各项服务对资源的使用限额,如Apache, MySQL,PHP

系统使用和优化的原则

+始终保留一定量的空闲资源

-多少合适?根据应用的特点,比如是否有突发性使用增长?

-日常情况下,保留至少 60% 的系统资源,以应付突发使用增长。

-日常情况下,资源使用率达到 80% 时,你必须有所行动了,尤其是web应用。

+系统硬件达到合理的配置(以适合应用的特点为依据,资源消耗均衡为目标)

-系统性能的水桶理论

系统使用和优化的原则

+应用软件对资源的使用要均衡(理想目标)

 怎么样就算是均衡了?我也在摸索中……

 理想状况为:CPU 消耗到50% 的时候,磁盘的带宽也到50% ,磁盘的tps 也到50% ,内存使用也到50%( 除去可以提供给cache 的内存)

开始第5个话题

+性能分析的目的

+性能分析相关的人

+性能相关的各个环节

+系统使用和优化的原则

典型应用对系统资源使用的特点

+常见的性能分析工具介绍

+性能分析及优化的案例

典型应用对系统资源使用的特点

+声明

这部分内容主要是本人在网站工作多年的一些实践经验积累,所以这些经验并不完全适用于其他的应用环境。

在我的经验中,大多数的硬件性能问题主要和CPU磁盘、内存相关, 还没有遇到因为开发语言的运行效率对整个应用的性能造成影响,而应用程序设计的缺陷和数据库查询的滥用反倒是最最常见的性能问题。

需要注意的是,大多数情况下,虽然性能瓶颈的起因是程序性能差或者是内存不足或者是磁盘瓶颈等各种原因,但最终表现出的结果就是CPU耗尽,系统负载极高,响应迟缓,甚至暂时失去响应,因此我们观察服务器状况时,最先看的就是系统负载和CPU空闲度。

典型应用对系统资源使用的特点

+动态内容为主的Web应用

+静态内容为主的Web应用 (Squid Cache)

+数据库应用

+软件下载

+流媒体服务

典型应用对系统资源使用的特点

+动态内容为主的Web应用

-频繁执行程序,如 Perl, PHP, Java 等,消耗CPU严重

-提供并发用户访问,因此系统进程数多,消耗内存多,当内存不足时,使用交换内存也会增加CPU的开销

-磁盘的写IO比较频繁(主要为随机写),比如生成cache文件,更新session文件等。

-内存充足时读取的内容可以被cache住,cache的命中率和文件更新的频繁程度成反比,磁盘的读IO相对较小

典型应用对系统资源使用的特点

+静态内容为主的Web应用 (Squid Cache)

 网络带宽瓶颈

 小文件的随机读取频繁,内存充足时可以缓解磁盘随机读的压力

 系统内存不足时磁盘IO 量会比较大(读、写、交换内存),因此增加CPU 的开销

典型应用对系统资源使用的特点

+数据库应用

-数据库查询语句复杂,大量的 where 子句,order by, group by 排序等,CPU容易出现瓶颈

-表太大时,查询遍历全表造成磁盘读的IO量大,容易出现读IO等待的情况

-数据更新量大或者更新频繁时,造成磁盘写的IO量大

-内存不足时频繁使用交换内存

典型应用对系统资源使用的特点

+软件下载

网络带宽瓶颈

存储系统带宽瓶颈()

+ 流媒体服务

 网络带宽瓶颈

 存储系统带宽瓶颈)

开始第6个话题

+性能分析的目的

+性能分析相关的人

+性能相关的各个环节

+系统使用和优化的原则

+典型应用对系统资源使用的特点

常见的性能分析工具介绍

+性能分析及优化的案例

常见的性能分析工具介绍

+Vmstat

+Top

+Free

+Uptime

+sysstat 工具包

+Iozone

+Strace

希望看完以上工具的使用说明,让你能够知道如何判断系统瓶颈在那里、内存是否够用、CPU是否够用、磁盘IO是否够用、网络和磁盘带宽是否够用等问题。

工具介绍-vmstat

vmstat是一个很全面的性能分析工具,可以观察到系统的进程状态、内存使用、虚拟内存使用、磁盘的IO中断、上下问切换、CPU使用等。系统性能分析工具中,我使用最多的是这个,除了 sysstat 工具包外,这个工具能查看的系统资源最多。

对于 Linux 的性能分析,100%理解 vmstat 输出内容的含义,那你对系统性能分析的能力就算是基本掌握了。

我这里主要说明一下这个命令显示出的部分数据代表的含义,和它反映出系统相关资源的状况。输出内容共有 6 类,分别说明如下。

工具介绍-vmstat

+Vmstat的输出格式如下(CentOS 3.3)

procs ———–memory———- —swap– —–io—- –system– —-cpu—-
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 160 223172 383344 3002376 0 0 0 6 0 0 1 0 99 0
0 0 160 223108 383344 3002376 0 0 0 0 4492 2261 1 0 99 0
0 0 160 222980 383344 3002636 0 0 0 412 4601 2277 1 1 98 0
2 0 160 222788 383344 3002636 0 0 0 0 4770 2391 1 1 99 0
1 0 160 222660 383344 3002636 0 0 0 80 4903 2488 1 0 99 0
0 0 160 222532 383344 3002896 0 0 0 0 4381 2074 1 1 99 0
0 0 160 222404 383344 3002896 0 0 0 0 4568 2321 1 0 99 0
0 0 160 222340 383348 3002892 0 0 0 428 4452 2178 1 1 99 0
工具介绍-vmstat

+Procs

r:

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

b:

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

工具介绍-vmstat

+Memory

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

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

– free: 空闲的物理内存

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

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

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

工具介绍-vmstat

+Swap

-si: 交换内存使用,由磁盘调入内存

-so: 交换内存使用,由内存调入磁盘

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

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

工具介绍-vmstat

+Io

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

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

随机磁盘读写的时候,这 值越大(如超出1M), 能看到CPU IO 等待的值也会越大

工具介绍-vmstat

+System

in: 每秒产生的中断次数

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

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

工具介绍-vmstat

+Cpu

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

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

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

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

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

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

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

工具介绍-vmstat

+情景分析

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

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

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

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

-Cpu wa: 稍微有些高

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

工具介绍-top

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

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

工具介绍-top

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

top - 15:57:49 up 184 days, 22:29, 1 user, load average: 0.07, 0.04, 0.01
Tasks: 76 total, 1 running, 75 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.6% us, 0.3% sy, 0.0% ni, 99.0% id, 0.0% wa, 0.1% hi, 0.0% si
Mem: 4149144k total, 3955340k used, 193804k free, 383444k buffers
Swap: 2040212k total, 160k used, 2040052k free, 3035036k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2786 www 16 0 1784m 423m 354m S 3 10.5 9:00.14 varnishd
1 root 16 0 2332 552 472 S 0 0.0 0:01.07 init
2 root RT 0 0 0 0 S 0 0.0 0:02.94 migration/0

工具介绍-top

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

top - 15:59:28 up 177 days, 5:15, 1 user, load average: 163.96, 201.91, 198.22
Tasks: 390 total, 147 running, 90 sleeping, 0 stopped, 153 zombie
Cpu(s): 85.9% us, 14.1% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 4149140k total, 3664784k used, 484356k free, 553480k buffers
Swap: 8289500k total, 61144k used, 8228356k free, 2372500k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27016 www 16 0 87864 8520 5132 R 3 0.2 0:05.16 php-cgi
27176 www 16 0 85952 6892 4676 R 3 0.2 0:01.17 php-cgi
27043 www 16 0 88388 9536 4888 R 2 0.2 0:05.02 php-cgi
27048 www 16 0 86736 7584 4584 R 2 0.2 0:05.17 php-cgi
27100 www 16 0 86060 7256 4900 R 2 0.2 0:04.51 php-cgi

工具介绍-top

+ top 看到的内存的说明(Mem的第2)

-actv

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

-in_d

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

-in_c

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

工具介绍-top

+问题?

in_d  in_c 以及 cache, buffer 的内存有何不同?

我的理解:

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

工具介绍-top

 top 看到的进程所处的几种状态(STAT)

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

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

– S 休眠中

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

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

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

– < 高优先级的进程

– N 低优先级

有时候一个进程会有多个状态的标志,比如SWNSW

工具介绍-top

+情景分析

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

-1)

+

-2)

-

工具介绍-free

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

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

total used free shared buffers cached
Mem: 4144696 4127236 17460 0 187548 1993072
-/+ buffers/cache: 1946616 2198080
Swap: 4192956 160 4192796

工具介绍-free

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

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

工具介绍-free

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

这行最容易让人迷惑。

它显示的第一个值(used这一列)是这样得来的:

Memused - Membuffers - Memcached

它显示的第二个值(free这一列)是这样得来的:

Memfree + Membuffers + Memcached

工具介绍-free

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

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

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

工具介绍-uptime

最简便的查看系统负载的工具,系统负载越小,系统运行状况越好,对于系统负载处在什么范围内比较合适,我想是没有定论的,我介绍一下我的习惯。

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

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

工具介绍sysstat工具包

这个工具包提供了著名的 sar 命令,还有非常实用的 iostat, mpstat, sa1, sa2 等命令。

这几个命令可实现前面提及工具大多数的功能,除此之外,还能查看系统的网络带宽状况、每块磁盘使用状况、每个磁盘分区的使用状况等。

工具介绍sysstat工具包

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

工具介绍-其他

+Iozone

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

+Strace

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

+其他

开始第7个话题

+性能分析的目的

+性能分析相关的人

+性能相关的各个环节

+系统使用和优化的原则

+典型应用对系统资源使用的特点

+常见的性能分析工具介绍

性能分析及优化的案例

性能分析及优化的案例

+动态内容为主的网站

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

动态内容为主的网站

+该网站系统结构说明

Dell2650 服务器单颗Xeon 3.0G CPU1G 内存,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语句,whereorder by子句上的字段建索引,程序增加Cache机制,再次使服务恢复正常。

动态内容为主的网站

+第四次优化

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

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

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

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

动态内容为主的网站

+网站结构优化

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

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

动态内容+Cache为主的网站

+该网站系统结构说明

 多台Web 前端服务器配置都为单颗Xeon 3.0G CPU4G 内存,73G SCSI磁盘

 操作系统 CentOS 3.3

 多台MySQL 数据库服务器

 基于PHP 开发的应用

动态内容+Cache为主的网站

+该应用的特点

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

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

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

动态内容+Cache为主的网站

+问题描述

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

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

+性能分析

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

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

动态内容+Cache为主的网站

+原因分析

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

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

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

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

动态内容+Cache为主的网站

+优化办法

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

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

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

动态内容+Cache为主的网站

+优化办法

-使用tmpfscache磁盘(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://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/admin-guide/

Sysstat 工具集

http://freshmeat.net/projects/sysstat/

其他查看系统的 man 手册

结束啦!

谢谢参与!

fulin 系统

squid 日志分析

2009年2月9日

 

通过日志来查看 squid 的一些基本的运行状态:

1. access.log

配置语句:

logformat combined %>a %ui %un [%tl] “%rm %ru HTTP/%rv” %Hs %<st “%{Referer}>h” “%{User-Agent}>h” %Ss:%Sh:%tr
cache_access_log /data1/logs/access.log combined

打下的log格式为:

125.71.196.17 - - [14/May/2008:12:16:13 +0800] “GET http://you.video.sina.com.cn/b/13441121-1212188024.html HTTP/1.1″ 200 8820 “http://you.video.sina.com.cn/” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)” TCP_MEM_HIT:NONE:21089

可以通过脚本查看一些统计信息,如各种反应状态所占的比例,通常较好的情况下HIT所占的比例(应该就是所谓的命中率)可以在70%~80%

$requests = $hits = $kbytes_out = $diskread = $diskwrite = "";

$command = “/usr/local/squid/bin” . “/squidclient -h {$ip} -p 80 mgr:5min”;

$pf = @popen($command, “r”);

if ($pf)
{
while (!feof($pf))
{
$s = trim(fgets($pf));

if (strpos($s, “client_http.requests”) !== false)
{
//client_http.requests = 78.816658/sec
$requests = str_replace(”/sec”, “”, trim(substr($s, strpos($s, “=”)+1)));
}

if (strpos($s, “client_http.hits”) !== false)
{
//client_http.hits = 56.603327/sec
$hits = str_replace(”/sec”, “”, trim(substr($s, strpos($s, “=”)+1)));
}

if (strpos($s, “client_http.kbytes_out”) !== false)
{
//client_http.kbytes_out = 2728.756667/sec
$kbytes_out = str_replace(”/sec”, “”, trim(substr($s, strpos($s, “=”)+1)));
}

if (strpos($s, “syscalls.disk.reads”) !== false)
{
//syscalls.disk.reads = 341.276664/sec
$diskread = str_replace(”/sec”, “”, trim(substr($s, strpos($s, “=”)+1)));
}

if (strpos($s, “syscalls.disk.writes”) !== false)
{
//syscalls.disk.writes = 150.846666/sec
$diskwrite = str_replace(”/sec”, “”, trim(substr($s, strpos($s, “=”)+1)));
}
}
}

@pclose($pf);

if ($requests == “” && $hits == “”)
{
printf(”[%02d]IP: %s \t\t 返回为空或者无法连接\n”, $i, $ip);
}
else
{
printf(”[%02d]IP:%s\t命中率:%u%% \t总请求:%u 次/秒\tSquid命中:%u 次/秒\t流量:%u K/秒\t磁盘读/写:%u/%u 次/秒\n”, $i,
$ip, ($hits/$requests)*100, $requests, $hits, $kbytes_out, $diskread, $diskwrite);
//printf(”[%02d] IP: %s\t命中率: %u%% \t总请求: %u 次/秒\tSquid命中: %u 次/秒\t流量: %u K/秒\t磁盘读/写: %u/%u 次/秒
\n”, $i, $ip, (($diskread-$diskwrite)/$diskread)*100, $requests, $hits, $kbytes_out, $diskread, $diskwrite);
}

 

PS:官方文档中关于Result Codes的说明
============================================================

TCP_HIT
A valid copy of the requested object was in the cache.

TCP_MISS
The requested object was not in the cache.

TCP_REFRESH_HIT
The requested object was cached but STALE. The IMS query for the object resulted in “304 not modified”.

TCP_REF_FAIL_HIT
The requested object was cached but STALE. The IMS query failed and the stale object was delivered.

TCP_REFRESH_MISS
The requested object was cached but STALE. The IMS query returned the new content.

TCP_CLIENT_REFRESH_MISS
The client issued a “no-cache” pragma, or some analogous cache control command along with the request. Thus, the cachehas to refetch the object.

TCP_IMS_HIT
The client issued an IMS request for an object which was in the cache and fresh.

TCP_SWAPFAIL_MISS
The object was believed to be in the cache, but could not be accessed.

TCP_NEGATIVE_HIT
Request for a negatively cached object, e.g. “404 not found”, for which the cache believes to know that it isinaccessible. Also refer to the explainations for negative_ttl in your squid.conf file.

TCP_MEM_HIT
A valid copy of the requested object was in the cache and it was in memory, thus avoiding disk accesses.

TCP_DENIED
Access was denied for this request.

TCP_OFFLINE_HIT
The requested object was retrieved from the cache during offline mode. The offline mode never validates any object, seeoffline_mode in squid.conf file.

UDP_HIT
A valid copy of the requested object was in the cache.

UDP_MISS
The requested object is not in this cache.

UDP_DENIED
Access was denied for this request.

UDP_INVALID
An invalid request was received.

UDP_MISS_NOFETCH
During “-Y” startup, or during frequent failures, a cache in hit only mode will return either UDP_HIT or this code.Neighbours will thus only fetch hits.

NONE
Seen with errors and cachemgr requests.

The following codes are no longer available in Squid-2:

ERR_*
Errors are now contained in the status code.

TCP_CLIENT_REFRESH
See: TCP_CLIENT_REFRESH_MISS.

TCP_SWAPFAIL
See: TCP_SWAPFAIL_MISS.

TCP_IMS_MISS
Deleted, TCP_IMS_HIT used instead.

UDP_HIT_OBJ
Hit objects are no longer available.

UDP_RELOADING
See: UDP_MISS_NOFETCH.

后面找到了中文版,补充全一些:
access.log 结果编码

相应于HTTP请求,下列标签可能出现在access.log文件的第四个域。

TCP_HIT

Squid发现请求资源的貌似新鲜的拷贝,并将其立即发送到客户端。

TCP_MISS

Squid没有请求资源的cache拷贝。

TCP_REFRESH_HIT

Squid发现请求资源的貌似陈旧的拷贝,并发送确认请求到原始服务器。原始服务器返回304(未修改)响应,指示squid的拷贝仍旧是新鲜的。

TCP_REF_FAIL_HIT

Squid发现请求资源的貌似陈旧的拷贝,并发送确认请求到原始服务器。然而,原始服务器响应失败,或者返回的响应Squid不能理解。在此情形下,squid发送现有cache拷贝(很可能是陈旧的)到客户端。

TCP_REFRESH_MISS

Squid发现请求资源的貌似陈旧的拷贝,并发送确认请求到原始服务器。原始服务器响应新的内容,指示这个cache拷贝确实是陈旧的。

TCP_CLIENT_REFRESH_MISS

Squid发现了请求资源的拷贝,但客户端的请求包含了Cache-Control: no-cache指令。Squid转发客户端的请求到原始服务器,强迫cache确认。

TCP_IMS_HIT

客户端发送确认请求,Squid发现更近来的、貌似新鲜的请求资源的拷贝。Squid发送更新的内容到客户端,而不联系原始服务器。

TCP_SWAPFAIL_MISS

Squid发现请求资源的有效拷贝,但从磁盘装载它失败。这时squid发送请求到原始服务器,就如同这是个cache丢失一样。

TCP_NEGATIVE_HIT

在对原始服务器的请求导致HTTP错误时,Squid也会cache这个响应。在短时间内对这些资源的重复请求,导致了否命中。 negative_ttl指令控制这些错误被cache的时间数量。请注意这些错误只在内存cache,不会写往磁盘。下列HTTP状态码可能导致否定 cache(也遵循于其他约束): 204, 305, 400, 403, 404, 405, 414, 500, 501, 502, 503, 504。

TCP_MEM_HIT

Squid在内存cache里发现请求资源的有效拷贝,并将其立即发送到客户端。注意这点并非精确的呈现了所有从内存服务的响应。例如,某些cache在内存里,但要求确认的响应,会以TCP_REFRESH_HIT, TCP_REFRESH_MISS等形式记录。

TCP_DENIED

因为http_access或http_reply_access规则,客户端的请求被拒绝了。注意被http_access拒绝的请求在第9域的值是NONE/-,然而被http_reply_access拒绝的请求,在相应地方有一个有效值。

TCP_OFFLINE_HIT

当offline_mode激活时,Squid对任何cache响应返回cache命中,而不用考虑它的新鲜程度。

TCP_REDIRECT

重定向程序告诉Squid产生一个HTTP重定向到新的URI(见11.1节)。正常的,Squid不会记录这些重定向。假如要这样做,必须在编译squid前,手工定义LOG_TCP_REDIRECTS预处理指令。

NONE

无分类的结果用于特定错误,例如无效主机名。

相应于ICP查询,下列标签可能出现在access.log文件的第四域。

UDP_HIT

Squid在cache里发现请求资源的貌似新鲜的拷贝。

UDP_MISS

Squid没有在cache里发现请求资源的貌似新鲜的拷贝。假如同一目标通过HTTP请求,就可能是个cache丢失。请对比UDP_MISS_NOFETCH。

UDP_MISS_NOFETCH

跟UDP_MISS类似,不同的是这里也指示了Squid不愿去处理相应的HTTP请求。假如使用了-Y命令行选项,Squid在启动并编译其内存索引时,会返回这个标签而不是UDP_MISS。

UDP_DENIED

因为icp_access规则,ICP查询被拒绝。假如超过95%的到某客户端的ICP响应是UDP_DENIED,并且客户端数据库激活了(见附录A),Squid在1小时内,停止发送任何ICP响应到该客户端。若这点发生,你也可在cache.log里见到一个警告。

UDP_INVALID

Squid接受到无效查询(例如截断的消息、无效协议版本、URI里的空格等)。Squid发送UDP_INVALID响应到客户端。

HTTP响应状态码

下面列出了数字HTTP响应CODE和理由短句。注意Squid和其他HTTP客户端仅仅关注这些数字值。理由短句是纯解释性的,不会影响响应的意义。对每个状态码,也提供了一个到RFC 2616的具体节的索引。注意状态码0和600是squid使用的非标准的值,不会在RFC里提到。

HTTP response status codes:

Code Reason phrase RFC 2616 section
0 No Response Received (Squid-specific) N/A
1xx Informational 10.1
100 Continue 10.1.1
101 Switching Protocols 10.1.2
2xx Successful 10.2
200 OK 10.2.1
201 Created 10.2.2
202 Accepted 10.2.3
203 Non-Authoritative Information 10.2.4
204 No Content 10.2.5
205 Reset Content 10.2.6
206 Partial Content 10.2.7
3xx Redirection 10.3
300 Multiple Choices 10.3.1
301 Moved Permanently 10.3.2
302 Found 10.3.3
303 See Other 10.3.4
304 Not Modified 10.3.5
305 Use Proxy 10.3.6
306 (Unused) 10.3.7
307 Temporary Redirect 10.3.8
4xx Client Error 10.4
400 Bad Request 10.4.1
401 Unauthorized 10.4.2
402 Payment Required 10.4.3
403 Forbidden 10.4.4
404 Not Found 10.4.5
405 Method Not Allowed 10.4.6
406 Not Acceptable 10.4.7
407 Proxy Authentication Required 10.4.8
408 Request Timeout 10.4.9
409 Conflict 10.4.10
410 Gone 10.4.11
411 Length Required 10.4.12
412 Precondition Failed 10.4.13
413 Request Entity Too Large 10.4.14
414 Request-URI Too Long 10.4.15
415 Unsupported Media Type 10.4.16
416 Requested Range Not Satisfiable 10.4.17
417 Expectation Failed 10.4.18
5xx Server Error 10.5
500 Internal Server Error 10.5.1
501 Not Implemented 10.5.2
502 Bad Gateway 10.5.3
503 Service Unavailable 10.5.4
504 Gateway Timeout 10.5.5
505 HTTP Version Not Supported 10.5.6
6xx Proxy Error N/A
600 Unparseable Response Headers (Squid-specific) N/A

假如Squid从原始服务器没有接受到任何响应,你可以在access.log里看到状态码 0 。假如Squid接受到的响应没有包含HTTP头部,就会出现状态码 600 。在少数情况下,某些原始服务器仅发送响应body,而忽略了任何头部。

access.log对端编码

下列编码可能出现在access.log的第9域。

NONE

这指明Squid对本次请求,不会与任何其他服务器(邻居或原始服务器)通信。它通常与cache命中、拒绝请求、cache管理请求、错误、和所有的ICP查询这些类型联合出现。

DIRECT

Squid直接转发请求到原始服务器。该域的第2半部分显示原始服务器的IP地址,或主机名–假如禁止了log_ip_on_direct。

SIBLING_HIT

在姐妹cache返回ICP或HTCP命中后,Squid发送请求到姐妹cache。

PARENT_HIT

在父cache返回ICP或HTCP命中后,Squid发送请求到父cache。

DEFAULT_PARENT

Squid选择该父cache,因为其在squid.conf的cache_peer行里被标志为default。

FIRST_UP_PARENT

Squid转发请求到该父cache,因为它是位于已知活跃列表里的第一个父cache。

FIRST_PARENT_MISS

Squid转发请求到该父cache,它第一个响应ICP/HTCP丢失消息。换句话说,对这个特殊的ICP/HTCP查询,在这个特殊时刻,被选 中的父cache有最佳的往返时间(RTT)。注意标准RTT可能被人工矫正过,取决于cache_peer指令的weight选项。

CLOSEST_PARENT_MISS

Squid选择该父cache,因为它报告到原始服务器的RTT最低。这点仅在2个cache都激活了netdb,并且原始服务器(或在同一子网内的其他server)返回ICMP ping消息。

CLOSEST_PARENT

这点类似CLOSEST_PARENT_MISS,除了RTT计算不是来自ICP/HTCP响应消息外。代替的,它们来自Squid保留的更老的计算方式,例如netdb交换功能。

CLOSEST_DIRECT

Squid基于netdb算法,转发请求到原始服务器。这点在满足下述任何条件时发生:

  • 1)在Squid和原始服务器之间的RTT小于配置的minimum_direct_rtt值。
  • 2)在Squid和原始服务器之间的标准路由跳数少于配置的minimum_direct_hops值。
  • 3)在ICP/HTCP响应里返回的RTT值,指示Squid离原始服务器近于任何其他邻居。
ROUNDROBIN_PARENT

Squid转发请求到该父cache,因为设置了round-robin选项,并且它有最低的使用计数器。

CD_PARENT_HIT

Squid基于cache摘要算法(见10.7节)转发请求到该父cache。

CD_SIBLING_HIT

Squid基于cache摘要算法转发请求到该姐妹cache。

CARP

Squid选择该父cache,基于cache数组路由协议算法(见10.9节)。

ANY_PARENT

作为最后的手段,Squid选择该父cache,因为没有其他方法能选择可行的下一跳。

注意大部分上述编码可能以TIMEOUT_开头,这表明在等待ICP/HTCP响应时发生超时。
可使用icp_query_timeout指令来调整超时。

例如:

gawk ‘{print $NF}’ access.log |sort|uniq -c|sort -nr

15508 TCP_NEGATIVE_HIT:NONE 在对原始服务器的请求导致HTTP错误时,Squid也会cache这个响应。在短时间内对这些资源的重复请求,导致了否命中。
8212 TCP_IMS_HIT:NONE  客户端发送确认请求,Squid发现更近来的、貌似新鲜的请求资源的拷贝。Squid发送更新的内容到客户端,而不联系原始服务器。(这指明Squid对本次请求,不会与任何其他服务器(邻居或原始服务器)通信。)
3771 TCP_HIT:NONE Squid发现请求资源的貌似新鲜的拷贝,并将其立即发送到客户端。
3468 TCP_MISS :D IRECT Squid没有请求资源的cache拷贝。(Squid直接转发请求到原始服务器)
2379 TCP_MEM_HIT:NONE  从内存的响应
1876 TCP_DENIED:NONE 因为http_access或http_reply_access规则,客户端的请求被拒绝了   全是错误地址链接
1732 TCP_REFRESH_HIT :D IRECT Squid发现请求资源的貌似陈旧的拷贝,并发送确认请求到原始服务器。原始服务器返回304(未修改)响应,指示squid的拷贝仍旧是新鲜的。(Squid直接转发请求到原始服务器)
708 TCP_CLIENT_REFRESH_MISS :D IRECT Squid发现了请求资源的拷贝,但客户端的请求包含了Cache-Control: no-cache指令。Squid转发客户端的请求到原始服务器,强迫cache确认。 (Squid直接转发请求到原始服务器)
7 TCP_MISS:NONE Squid没有请求资源的cache拷贝。(这指明Squid对本次请求,不会与任何其他服务器(邻居或原始服务器)通信)

fulin 互联网, 存储, 开源, 服务器, 系统 ,

页: 前页 1 2 3 ...61 62 63 64 65 66 67 68 69 后页
页: 前页 1 2 3 ...61 62 63 64 65 66 67 68 69 后页