故障现象:
Pool相比传统RAID Group在灵活性上优势更为明显，因此越来越多的朋友也开始使用Pool，但由于Pool本身的复杂性，也使得对它的排错难度更大。下面在这里与大家分享以下如何解决Pool的性能问题。

解决方案:
导致Pool性能问题的因素

• 在对性能要求很高的LUN上启用了压缩或精简资源调配（Thin Provisioning）
  
• 单线程顺序I/O不能平均的分布在所有可用磁盘上
  
• 没有足够的剩余空间让FAST VP在层级之间重定位（relocate）数据（参考emc274840和emc286484）
  
• Pool中繁忙LUN之间的链接竞争（Linked Contention，参考emc188729）。例如，当源LUN与保留LUN池（Reserved LUN Pool）或克隆在同一个Pool里时，还对它们做重定位。
  
• 性能分析（参考emc284523）显示某些层级I/O饱和了，但其它层级相对空闲。例如，使用了FAST VP的SAS/NL-SAS Pool，要求高性能的I/O都冲着SAS盘去了，但可能SAS层级未必有足够的盘来消化请求的I/O。
  
• 如果Pool启用了FAST Cache，但FAST Cache盘过载了。参考emc291582如何排错此类问题。
  
• 在一个单层级的大型Pool中，I/O负载可能在磁盘中间变得不均衡。在FLARE和VNX OE R32之前，FAST VP不能在层级内部做负载均衡。然而，如果有多个层级，FAST VP可以通过跨层级向上/向下迁移slice的方式来更为平均的分散负载。
  
• 如果LUN的策略设置为“Highest Available”，这可能会导致高性能磁盘（SAS/FLASH）被保留用于并不需要最高性能的I/O。如果所有LUN都设置为“Auto Tier”，那么FAST就能更为灵活的将要求高性能的I/O移动到更快的磁盘上。

• 为启用FAST VP的Pool添加EFD/SSD盘可以极大的增强性能
  
• 为“性能层级（SAS或FC）”添加磁盘可以帮助分散高负荷I/O，不过由于Pool容量也会按比例增加，所以性能要求也会相应提升。
  
• 对于要求高性能的大I/O，考虑使用MetaLUN，这样可以将I/O更平均的分散到更多的磁盘上。参考emc226845有关MetaLUN最佳实践。MetaLUN无法使用FAST VP、压缩以及精简资源调配，但可以使用FAST Cache。
  
• 对应用程序的不同部分使用Pool的最佳实践是将形态不同以及存在竞争的I/O单独放在各自的Pool里，比如数据库的日志和数据最好能放在不同的Pool里，这相比共享Pool的可用性更高，而且可以仅为有需要的LUN启用FAST Cache，我们可以为数据LUN启用FAST Cache，但不为日志LUN启用（FAST Cache最佳实践emc251589）
  
• Thick Pool LUN或RAID GROUP LUN比Thin LUN以及使用压缩的LUN在性能上更好（压缩的LUN也是Thin LUN）
  
• 如果Pool的剩余空间小于10%，那可能需要添加更多的磁盘或迁移某些LUN到其他位置，因为FAST VP需要足够的空间做数据重定位。
  
• 如果VNX的一个或多个大型Pool仅有一个层级，那么可以考虑升级到VNX OE R32（05.32.000.5.xxx）。当有新盘加入Pool时，FAST VP能够自动重定位数据（R32）。
  
• R32允许新层级使用不同的RAID级别。最佳实践是为“性能层级（SAS）”和“极限性能层级（EFD）”使用RAID5，“容量层级（NL-SAS）”使用RAID6，这仅在添加新层级时可行，为现有层级添加磁盘是不能改变RAID级别的。
  
• 保持策略设置为“Highest Available”的LUN的数量尽可能的少，从而避免这些LUN独占高性能磁盘。可以的话，所有LUN都应该设置为“Auto-Tier”或”Start High, then auto-tier”（VNX OE 05.32+）