大多数最新存储技术的设计均能够提供在性能方面的明显改善。例如，更快的驱动或更大的缓存，但是，这并不总是发生。

　　当与客户讨论SAN故障排除时，我们经常发现那些最意想不到的状况往往发生在部署了新技术之后，并且总是由虚拟或物理主机通过存储基础设施上的不同点的错误配置所引起的。

　　由于这个原因，那些在更快的存储方面下血本投资的企业客户却最终发现他们的应用程序性能并没有得到很好的改善。

　　当我们查看到底是什么原因导致应用程序的性能表现不佳时，可以从如下几个较为固定的方面进行排查。这些措施包括：

　　存储阵列配置

　　例如，我们经常会发现一个面向客户的数据库或其他应用程序远比我们所预期的更受欢迎。一款新的面向客户的应用程序最初预计只有6万名用户，结果其用户数量突破了300万，这无疑大大超出了存储、网络和主机的负荷能力。

　　这种情况通常是这样造成的：最初的设计是足够的，在彼时的情况下，其架构是能够承受最初设计的相关需求的。但是，一旦应用程序是在阵列负载之下，其本身并不总是足够能处理的。另外，事情总是变化的，期待一个存储阵列能够在未来长达三至五年的时间内满足所有的工作负载需求也是太过乐观了。

　　因此，衡量组成I/O栈的组件成为了关键，这需要在正确的粒度级别。我们经常看到测量比毫秒更长的时间间隔，这就正是您所需要查看的I/O性能。

　　如果您不针对每个I / O都进行实时的查看，某些问题可能无法引起足够的重视。从实时数据中查询历史数据是一种常见的错误。同时，大多数阵列供应商只保留数据24小时，所以在问题发生之前，可能无法对其进行识别，并发现其趋势。

　　交换机问题

　　当我们进入到堆栈的第二部分：光纤通道交换机时，经常发生交换机的性能与供应商没有太大关系的问题。博科和思科的SAN交换机产品非常棒，就像阵列一样，其在堆栈中只是一个设备。

　　有些人认为他们可以得到除了SAN交换机之外，所有他们需要的性能信息。但不幸的是，事实并非如此。这就像我知道高速公路非常繁忙塞车(类似于吞吐量)，但我还是不一定能预料到我多久能回家(类似于延迟性)。而我家人关心的又是什么呢?我何时能到家。

　　我认为用户在存储基础设施上运行应用程序是一样的。我们所需要知道的是延迟时间。而关键的吞吐量则显得不那么重要。很明显，更具我们从客户那儿得到的反馈，测量交换机级别的吞吐量并不能很好的反映出I / O的状况。

　　物理层问题

　　连接不良往往导致重新发布命令，从而带来大量的通信。这会减慢数据库，削弱了闪存存储的优势。不管您买了多少闪存，如果您的物理层不够完整和健康，您都将无法充分利用您的投资。

　　队列深度

　　可能会导致实际速度变慢的另一个方面是队列深度，一个重要原因就在于其往往是由服务器团队设置的，而不是存储团队设置的。不幸的是，您企业的环境越大，就越难以管理这个问题。一个服务器管理员可以更改队列深度来增加自己的业绩，而这可能会影响其他用户(或服务器)的共享路径。

　　块的规模

　　读/写功能的大小需要与应用程序数据库的块大小匹配来存储。如果不调整为合适的块规模大小，其会导致性能问题。这将高度依赖于正在执行的应用程序的类型。显然，您可以通过更快的磁盘缓解这个问题，但即便如此，这也与正确的设置有很大的关系。

　　CPU配置

　　即使是在虚拟化环境中，物理服务器的CPU仍然是有限的。经常有客户增添很多物理设备却不增加CPU和内存。不管闪存驱动器是到位，这都可能会影响到应用程序的性能。要想让闪存为您企业应用程序的性能带来质的飞跃，请务必确保需要有足够的物理服务器和CPU 。

　　大多数性能问题都与存储无关

　　当应用程序的表现不如预期时，也可以是由于任何错误的配置方式造成的。通过我们终端到终端的监测经验估计，75%至85%的问题都不是由存储阵列的问题所造成的，而往往是堆栈里的别的东西造成的。并且，堆栈中的层数越多，您企业环境虚拟化越密集，问题就越糟糕。

　　查明这些问题的方法是通过对整个IT基础设施实施实时的监控和主动的性能管理，使任何不匹配的问题都能够在其发展成真正的故障之前被识别。这尤其适用于运行着数百甚至数千台服务器的大型数据中心，在这样的大型数据中心识别并确定某些问题就如同大海捞针一样。

　　那些依靠IT基础设施来支持关键任务活动的客户往往会发现，从成本角度考虑，在引进新技术之前，明智的做法是控制和详细掌握整个IT基础架构及其I / O性能。

　　在引进闪存之前，企业客户重要的是要对企业IT基础设施进行端到端的审查，这包括虚拟机，服务器，存储结构，存储阵列和LUN ，查明性能问题。这种端至端的审查可以让客户在正确的地方有的放矢的做出明智的投资，而不会造成投了大把钱，却没有收到预期的效果。