文档介绍：.
BestPracticeFromDOITWIKIJumpto:navigation,search版权声明：《EM济储最佳实践〉〉R22的版权归美国EM四司所有,［感谢DOSTOR网友/Arthas的全力翻译］。EM济储最佳实践R22中e,这样会有更短的响应时间。读，在另一方面来说，可能命中cache,也可能不命中cache；而对大部分随机的工作情形来说，读比写会有更高的相应时间，因为数据还是需要从磁盘里面抓取。如果要达到高的随机读取吞吐量，需要更好的协作（concurrency）。
［外］I/O的大小每一个的I/O都有一个固定的开销和一个变量的开销，后者决定丁其他的一些事情，例如I/O的大小。
大的I/O能提供更少的固定开销因为有着更大的数据。因而，对CLARiiON而言大的I/O比小块的I/O能提供更大的带宽。如果有足够的硬盘，在执行大的I/O的时候后段总线的速度将会成为系统的性能瓶颈。小块的随机访问应用（例如OLTP的瓶颈在丁磁盘（的个数），而且很少达到后端总线速率。
当设计OLTP的时候，必须要使用基丁磁盘（的个数）的IOP来衡量，而不是使用基丁总线的带宽来衡量。
然而，在一个CLARiiON存储系统里面，当I/O到了某一个特定的大小的时候，包括writecaching和prfetching都会被bypass掉。是决定用一个大的I/O请求还是把他分成几个顺序的请求，取决丁应用程序和它跟cache之间的相互作用。这些相互作用在“TheRaidengineCache”里会探讨到。
文件系统也可以影响到I/O的大小，这也在稍后的“Hostfile-systemimpact”中描述到。
［也］暂时的模式和峰值的表现(temporalpatternsandpeakactivities)应用的操作设计--如何去使用，什么时候去使用，什么时候需要去备份--都会影响到存储系统的负载。例如，用作随机访问的应用的存储系统，在备份和批量处理的时候，需要好的顺序性能。
一般来说，对OLTPW消息应用(任何跟大量随机访问I/O有关的),更高的并发处理能力(concurrency)会更好。当有更高的并发处理能力的时候，存储系统将会获得更高的吞吐量。使用异步I/O是一种获得更高的并发处理能力的通常的手法。对带宽而言，单线程的应用几乎不能有效地利用四块硬盘以上带来的好处，除非requestsize是非常大的(比2MM)，而此时如果顺序处理到磁盘的路径是唯一的时候，用户还是可以从有适度并发随机访问的光纤硬盘(每个硬盘的I/O在100以下)的设置中获得一个可接受顺序性能。
［外］主机文件系统影响在主机层次，通过指定最小最大的I/Orequestsize,文件系统也影响了应用I/O的特性。
［外］文件系统的缓冲和组合(coalesce)跟在存储系统上的cache相似的是，缓冲是文件系统提高性能的一种主要方式。
缓冲在大部分的情况下，文件系统的缓冲应该最大化，因为这能减少存储系统的负载。然而，还是会有一些意外。
一般来说，应用自己来调配缓冲，能避免文件系统的缓冲或者在文件系统的缓冲之外工作。这是基丁应用能更加有效的分配缓冲的假设之上。而且，通过避免文件系统的coalesce，应用更能控制I/O的响应时间。但是，正如在64位的服务器里RAM勺容量将会提升到32GB或者更多，这也就有可能把这个文件系统都放在缓冲里面。这就能使读操作在缓冲下，性能会有非常显着的提升。(写操作应该使用写透(write-through)的方式来达到数据的持续性。)结合Coalescing文件系统的coalesce能帮助我们从存储系统里获得更高的带宽。在大部分顺序访问的操作里面，，这种处理方式可以和备份程序一起把64KB的写操作结合
(coalesce)成一个完全stripe的写操作，这样在writecache被bypass的情况下，对丁带校验的Raid会更加有效果。
［外］最小化I/O的大小：文件系统的requestsize文件系统通常都被配置成一个最小的范围大小，例如4K己8KB或者64KB,这是提供给阵列的最小的不可分割的请求。应用使用的I/O在比这个范围大小要小的时候，会导致很多不必要的数据迁移和/或read-modify-write的情形出现。这也是考虑应用和文件系统文件的最佳设置的最好办法。(itisbesttoconsultapplicationandfilesystemdocumentationfortheoptimalsettings)而requestsize没有被文件系统限制的Rawpartit