磁盘性能对Web应用程序的影响（转）

现在有很多的网站应用都是基于LAMP的架构(M就是MySQL)，为了缓解数据库的读取访问压力，通常都会使用缓存机制，也就是查询一次数据库后在一定失效期内多次使用结果，从而减少数据库的频繁访问，以此来提高应用程序的响应度和执行效率。而对于缓存的实现机制，有多种方法实现，比如把缓存内容写在本地磁盘文件中，常用的有 Smarty 或者 Pear Cache_Lite 等软件，也有缓存在内存中的实现方式，比如使用 tmpfs 或者 memcached 等。


据我所了解到的情况，似乎使用磁盘文件来做缓存的用法更多些，实际上我是非常主张使用内存缓存机制的，这种方式性能更高，但是缺点就是可缓存的内容要受系统内存大小的限制，对于很多人来说，服务器的内存本来就比较紧张，更不会考虑内存缓存方式了。所以很多人都是首选使用磁盘文件缓存的方式，我下面来详细分析一下这种方式对网站整体性能的影响。


我们分两部分来分析：

1。磁盘的物理特性对随机读写性能的限制

2。网站访问量和磁盘缓存命中率的关系



1. 磁盘的物理特性对随机读写性能的限制
目前服务器采用的磁盘有SCSI的和SATA两种，前者性能更好，我们就以转速15000转的SCSI硬盘来做分析，这种SCSI盘的磁盘寻道时间在3.5~5毫秒，这意味着读取一个文件时，通常要等待3.5~5毫秒磁盘才能定位到存储文件的位置，如果频繁读取同一个文件，那么只需要一次磁盘定位，后面的多次读写就不需要等待磁盘定位，这样的读写性能是非常高的，这种访问也叫做持续磁盘访问，这方面通常的磁盘都能满足应用的需求。而如果频繁读取的是多个文件，并且每次访问的文件都不一样，那么每次读写都得等待磁盘寻址，这样算下来，每秒种也就能完成300次左右的访问，这种形式的访问，我们叫做随机磁盘访问，300次左右这是一个物理特性的限制，现在的磁盘技术单块磁盘无论如何也是无法超越这个上限的，提高磁盘随机存取的唯一方法，就是多块磁盘并发处理，将请求分担到多块磁盘上去。


在Linux/FreeBSD/Solaris等系统中，磁盘的读写也都有优化机制，对于读操作的优化，都通过使用空闲的内存做Cache来实现，也就是从磁盘上读取的文件内容会继续保存在内存中，以后的读取会先在内存中访问，所以只要空闲内存足够大，可以缓存很多磁盘文件；对于写操作的优化，Linux/FreeBSD都使用了异步的写，应用程序执行写调用后立即返回，而不用等待数据确实写到磁盘后再返回，这种方式很大程度上提高了程序的响应速度，对于持续写的操作也有很大的性能改善，但是对于随机写的性能改进却比较有限，毕竟磁盘仍然要完成大量随机寻址的操作是不能避免的。


很多人对于磁盘读写性能的认识不够清晰，有时候发现存储系统性能表现很差时，往往想到的是SCSI卡、SATA卡的性能问题或者是驱动程序的问题，而忽略了磁盘随机读写的性能瓶颈问题。


当磁盘的随机读写次数达到每秒300次左右时，就基本达到极限了，这时候IO系统就出现了性能瓶颈，会造成大量请求积压、进程等待、CPU资源耗尽等糟糕情况，所以我们一定要避免出现这样的情况，通常情况下应该让系统中每块磁盘的使用率不要超出50%，也就是不超过大约每秒150次随机访问。


系统的CPU使用有这样一个特点，磁盘访问越多，CPU消耗在iowait方面的资源也越多，尤其是随机磁盘访问时更加严重，根据我的观察经验，单块磁盘随机访问达到每秒150个时，CPU的iowait也会超出 30% 以上，留给应用程序能使用的CPU资源不足 70% 。在用于网站应用的服务器中，出现这样的情况是非常糟糕的，因为通常情况下我们对系统的使用率不应超过 50%，以保留服务器的访问量还能增加一倍的空间，所以通常CPU的使用也不应该超出 50%，这 50% 的CPU资源中，我们应该把更多的资源用于应用程序的处理，而不应该在 iowait 上面消耗太多，我认为比较合理的分配应该是平均 iowait 不超出 15% 最好，按照前面提到的150次随机磁盘访问消耗 30% 的 cpu 资源来计算，15% 的cpu资源大约可以完成每秒75次随机磁盘操作（单块磁盘），如果有多块磁盘来分担处理的话，15% 的 CPU资源应该可以完成更多随机磁盘操作。



2. 网站访问量和磁盘缓存命中率的关系
关于平均访问流量：以一个日访问量在1000万次PV的网站为例，我们假设全部访问内容都是由程序处理，并且 80% 的访问流量是由早晨、下午、晚上三个时间段组成，大约为 9~12个小时，为了方便计算我们就当成10个小时看，那么平均每小时的访问量计算方法如下：

1000万 * 80% / 10小时 = 80万请求

平均每秒的访问量计算方法如下：

1000万 * 80% / (10*3600) = 222次请求


关于高峰访问流量：实际情况中，不同网站的访问高峰也不完全相同，有的集中在早晨4个小时，有的可能集中在晚上的3个小时，也有的因为突发事件、热点事件等因素导致高峰时间段更不确定，我们暂不讨论这种情况。


通过前面的计算，我们可以得出 1000万次PV的网站每秒的请求数为 222 个。假设我们手头只有2台服务器，一台跑Apache，一台跑MySQL，那么就要求那台跑Apache的服务器每秒必须能够正常处理 222次用户请求，下面我们再来分析一下这样的访问量情况下，缓存的命中率应该达到什么范围才能保证磁盘IO不会成为性能瓶颈。


假设所有被访问的程序都使用了磁盘文件缓存机制，那么缓存的命中率和缓存的失效期对性能的影响就比较重要了，命中率高低、失效期长短和缓存文件的更新、创建是成反比的，磁盘读写越少越有助于发挥服务器的整体性能，因此我们一方面要设法提高缓存的命中率，另一方面又要在力求满足业务需求的前提下尽可能提高缓存失效期。


磁盘文件缓存由于要向磁盘写文件，访问量越大时往往需要缓存的内容也会越多，所以磁盘写的操作也越密集，而从缓存内容的大小来看，往往都是小文件的操作，一般都不会超出 256K，可能普遍都在 64K 的范围以内，按照每秒 222次访问，而磁盘的随机读写不超出 75次为指标（因为要求iowait不超出15%），那么可以用下面的方法计算缓存的最小命中率：

(222 – 75) / 222 ~= 0.67

也就是缓存的命中率要高于 67% 以上才行，如果低于这个值，那么在磁盘IO方面将会消耗更多的CPU时间，系统整体性能的发挥就受到了影响。


现在我们可以知道，一台日处理千万PV的服务器，和应用程序在磁盘IO环节的优化是分不开的，而在磁盘IO环节的优化，主要在于降低随机磁盘写的操作，希望我们在设计网站应用的时候，一定要对网站访问量和缓存的命中率做一些预估，以此来推算磁盘读写次数，从而对网站程序的设计起到指导作用。我们一定要避免为了缓解数据库或者其他网络存储的性能瓶颈问题，而又造成本地磁盘性能瓶颈的错误做法。



总结
上面说的是一个基于磁盘文件缓存的应用案例，在这种应用中，过于频繁的随机磁盘写会成为系统性能瓶颈，当然也有其他特点的应用，比如随机磁盘读很多的，象处理大量数据查询的数据库服务，还有ldap服务都是，也有非常消耗带宽的应用，比如流媒体和文件下载的服务，这类应用需要磁盘有很好的块文件读写能力。对于这些应用，除了应用程序尽量避免过早出现磁盘性能瓶颈外，也有一些通用的优化办法：

l        多块磁盘做条带化读写，比如用 Raid0 实现，也可以考虑软件实现，如SoftRaid，还有象Linux中的LVM（其他系统也有类似LVM的实现方案），这种优化是对写性能最好的优化。

l        用 Raid5 来优化读的性能

l        准备充足的内存来优化读的性能
http://home.phpchina.com/space.php?uid=29605&do=blog&id=185514