高速缓存大小对系统影响

IBM 存储事业部 裘殷雷

读高速缓存的原理是将经常被引用的数据存储在一个较小的但响应时间比底层存储介质要快的存储介质中。在磁盘存储系统中，前端的RAM存储器或/和处理器内存可被用来提供这一性能上的好处。在高速缓存中找到所需要的数据被称为“命中”，在高速缓存中没有找到所需要的数据被称为“缺失”。

写高速缓存的原理是允许以高速缓存的速度处理写I/O请求（即新的或被改变了的数据将被“清理”出高速缓存）。

HP VA7110可以提供最大容量为2GB的高速缓存，IBM FastT600提供的高速缓存的最大容量为256MB。尽管这些高速缓存的大小可能会给人留下较深的印象（仅仅在几年以前，128MB的高速缓存还是大容量的高速缓存），但中肯的问题应该是：客户需要多大的高速缓存就可以满足性能上的需要？系统有没有提供可以减少大容量高速缓存需求的性能工具？与容量较小的高速缓存相比，大容量高速缓存所带来的好处能否补偿所花费的成本？


在实践中，磁盘系统高速缓存的大小通常小于系统磁盘容量的1%。例如，本此配置73GB硬盘9个，实际容量600多GB，即使配置2GB高速缓存，缓存/容量比例也不到1/300。

我们假设系统需要处理30000个IO，假设Cache命中时每个IO需要1ms，Cache非命中时需要5ms。

根据概率，2GB Cache命中率约为1/300，考虑到智能算法等因素，将命中率提高10倍（这个值已经估计的足够大，远远超过智能算法能够达到得效率），按1/30计算。
30000 IO中，将有1000 IO从缓存中提取，另外29000IO需要从磁盘中读取，实际操作时间为：
1000* 1ms + 29000*5 ms = 146000ms = 146秒

如果Cache完全不命中时
30000ms * 5 = 15000ms = 150秒

两者相差不到 4%。而IBM FastT600的IOPS为45K，HP VA7410的IOPS为34K，两者相差32%。可见，在实际应用中，IBM FastT600的实际性能会比HP VA7410高30%左右。而且，HP VA7110只是HP VA7410的一个小型号，性能只会比HP VA7410更差。



很多情况下，会遇到一个极端情况，即如果应用的实际使用数据介于256MB到2GB之间，此时看上去采用HP VA7410所有数据都会在高速缓存内，而采用FastT6000则需要许多的磁盘IO。

实际上，很多中型平台如Windows NT, Windows 2000和基于UNIX的服务器，会有效地将处理器内存作为读高速缓存使用。与磁盘系统内的外部高速缓存相比，这一方式能够带来显著的好处。首先，访问已经存储在内存中的数据很明显要比使用I/O设备将其从外部RAM芯片中读入内存要快。其次， 去除I/O操作将减少处理器的使用（因为所运行的处理器指令的数量较少）。此外，由于减少了对磁盘系统和磁盘驱动器的使用，所以其它任务的性能将得到提高，而且还减少了性能调节的需要。
现在，服务器的内存往往大于几个GB，本此配置了8GB的内存，所以如果应用的实际使用数据介于256MB到2GB之间时，根本不会有多少磁盘的操作，因为所有的数据都会在内存中找到。

如果，一个数据在8GB的内存中没有找到，那么，在2GB的磁盘缓存中找到得概率就更小。因此，除非磁盘系统的高速缓存明显大于主机内存的高速缓存，否则磁盘系统实际上是对很少会被请求的数据进行了“双重高速缓存”操作，在这种磁盘系统高速缓存上的投资几乎没有什么回报。

“Unix系统通常在系统内存内部支持扩展读高速缓存，在大多数应用中这将能够减少对大容量外部高速缓存的需求。”
--Gartner集团，GG-DCS报告，1997年11月


综上所述，采用IBM FastT600的综合性能会远远高于 HP VA7110，虽然前者高速缓存为256MB，而VA7110可以配置到2GB。

有机个我觉得比较有意思的地方：

1. 按照文中说法，比如一个ESS，10TB，配置16GB和8GB CACHE的命中率区别仅仅是16/100000*10=0.16%和8/100000*10=0.08%的区别，也就是说对I/O的性能影响差别仅有0.08%，就是说裸盘总容量越大，越不应该选用大CACHE因为8GB CAHCE还是很贵的？

2. 比如1TB的ESS搭配8GB CACHE，CACHE命中率只有8/1000*10=8%这种数量级？同理，内存CACHE算法应该和阵列也差不多，一个512KB L2CACHE的PIII搭配256MB内存，CACHE命中率只有512/256/1024*10=1.9%？听起来就觉得可笑。



我觉得这篇文章是为了在某个案子中打HP 7110，普遍意义可能不高。

IBM好像4％的差异在IO数量较小的情况下（如例子的3万的IO）感觉不出来。
3万IO没有多少数据 就相差4s

但是如果IO大的话，呵呵那就感觉很明显了

400s 4000s不等的郁闷死了

－－－－－－－－－－－－－－－－－－－－－－－－－
IBM应该说的是在小IO的情况下，用的低档存储而且是IO较小的应用时高速缓存大小对系统影响不大。
不适合用来对ESS这样的高端存储做分析

“所以如果应用的实际使用数据介于256MB到2GB之间时，根本不会有多少磁盘的操作，因为所有的数据都会在内存中找到。”

那个4S的差别不能以绝对值来看，本身就是个估计数，误差可能非常大。如果差别都达到400秒了，总I/O时间也已经达到15000秒就是4个多小时，这么8分钟的差别还重要吗？

要看相对值，我相信作者本来也就是这个意思：(150-146)/150=2.7%，就是说2GB CACHE和无CACHE对性能只有2.7%的影响，就是说如果做上30000个随机I/O，无CACHE需要的时间为t，有2GB CACHE的时间应该在0.976t，差别这么小，我认为这个结论是可笑的，但是这个推理过程没有错。

错在哪里？作者在前面做了一堆假设，什么CACHE命中则I/O时间为1ms，不命中则5ms等，其中最核心的是以不容置疑的口气说：CACHE命中率按照目前算法绝对不可能超过CACHE与裸容量比值的10倍，就是这个有问题！

而且作者并没有说多大密度的I/O，只说30000个，没有说时间。这和存储设备的档次没关系，从作者的推理过程看不出任何一点不能适用于ESS这样的设备。

所以，我认为不是作者故意把错误的假设隐藏在无关紧要的其他假设中混淆视听以达到贬低HP大容量CACHE的目的，就是自己也是晕的。

是用来打EMC的
被EMC看到不要笑死

larryh的逻辑能力让人佩服。
不过在数据库的应用重，cache有时反而对数据库的影响却是负面的。

此话怎么讲？

以前上微机原理老是逃课，如何计算cache命中率都还给老师了。

还是larryh兄扎实。


http://www-900.ibm.com/cn/support/viewdoc/...d=2604033G16000
从IBM网站上转载了这篇搞笑文章:red: 对不住大家了。

SHALA别这样啊，作者又不是你。
你的转贴质量还是很高的，希望看到更多你的转贴

再说，这篇文章的前半部分的原则性说明还是很不错的。

只是，作者试图以存储设备本身为中心，将CACHE大小对应用性能的影响较小的问题说清楚，没有足够的高度，出发点不太对。我也认为在中低端存储上CACHE大小对应用性能的影响比想象的要小得多，但是这要从服务器/存储的布局结构、I/O负载与存储系统最大承受负载的比率、服务器或数据库CACHE（这在文章中有说，但分量很不够）几个方面来分析。

larryh我没什么了，来这就是学习交流的，错了也不怕，在这错总比在工作中错好啊。
写一点个人认为：

Cache的存储容量比存储的容量小得多，太小会使cache命中率太低；过大不仅会增加成本，而且当容量超过一定值后，命中率随容量的增加将不会有明显地增长。只要Cache的空间与存储空间在一定范围内保持适当比例的映射关系，Cache的命中率还是相当高的,特别是中低端的产品本身跑的商业应用对IO的性能要求不是很高，cache命中率相差不大这样决定了这些存储性能对应用影响不大。

对于高端应用中对于IO要求较高，在大量的分散的小文件的读取，高速缓存的容量越大，所能存储的预读数据就越多，在这些预读数据中能提取到所要读取的数据的机会就越大，大cache的优势就发挥出来了。

如果IO要求特别大，磁盘操作的文件大，读写频繁，磁盘负荷很繁重，Cache命中率相应要小很多，大Cache对性能提升帮助不大，更需要硬盘具有绝对的速度。

在以读操作的DSS应用中，CACHE却是是比较有用的。但在OLTP的系统中，以大量的随即的小的写操作，CACHE就未必能提高性能了。本来ORACLE的SGA中就有自己的缓冲区，有一套自己的管理算法，在额外加上操作系统的CACHE管理就不一定能起到好的作用。
具体没试过，只是理论是这个样子，还请CHAO_PING指教。

呵呵，fengwy还应该认真学习些啊。
这里说的cache不是内存开的cache，而是存储设备上的cache。