Fast Cache性能疑惑

多谢回答，

但在我这边看两个控制器的总iops都在4100左右，写iops在2300左右，write size 在40kb左右，Average Busy Queue Length都达到了200左右。    这个负载对于存储来说处于一个什么水平？

神奇的就是这4000iops 主要分布在6个RG中，最高的RG为10块disk的R10，它承受了1200iops，所有RG组最高的utilization才56%。

在analyzer中看到故障时刻两个控制器Bandwith/s在190MB左右，我看硬盘的ABQL基本都在12一下。还有那些方面能分析这个问题么？

write cache water mark 60-80是最佳实践，通常不用改动，除非针对特殊应用做个分析后做出对应调整。

宏观上排错顺序一般是这样的：

1. 看SP level：UT < 70%、Dirty Page是否存在过多95以上的点，如果是的话，就继续判断为什么会有force flush

2. 看LUN LEVEL：哪些LUN贡献的I/O最多，哪些LUN的reponse time过高了（大于20ms）

3. 看disk LEVEL：disk response time > 15ms，FC IOPS > 180，FC bandwidth > 12MB/s （仅供参考）

根据你之前的描述，force flush的可能比较大，FF就是过载，找出哪个RG过载需要仔细看NAR/NAZ file

     我假设你给出的数据都是SP Level的：

1. Total IOPS = 4100
2. Write IOPS = 2300
3. write size = 40KB -> large I/O
4. Read IOPS = 1800 -> R/W ratio = 1:1.8左右 -> write intensive workload

• Bandwith = 4100*40KB = 160MB/s < SP port 360MB/s (4G FC) -> port没有过载，但需要确认是否存在QueueFull
• 160MB/s，以12MB/s FC盘 RAID5来算，需要14块盘的RAID Group才能满足，但通常不会有人做这么大的RAID5，如果没有做metaLUN，160MB/s必然会过载一个R5的小RAID Group，即便是130MB/s的flush rate一样如此。如果这160MB/s的流量分布到了不同的RG，那另说。另外，R5是write-intensive I/O的大忌，如果你那不是R5就最好。
• ABQL = 200 -> 不能确定是否过载，建议看盘的ABQL，通常小于12还能接受

     总的来说，这个流量对整个存储来说不算大，你看下SP CPU就知道存储自己是否过载了。但如果都集中到某个点（RG）的话，就有可能在“点”上造成过载，具体问题还是需要看Analyzer log。

1、首先两个控制器UT都达到85%，且控制器整体都有较大的response time

2、我这边没有个别的lun有特殊贡献的，基本提供的iops都不多，最多的也就500iops。位于不同riad组的很多没有关系的lun在故障时刻response time都有明显增加。

3.、在disk level 没有看到单个iops >180的    最高的在140  所以完全看不到过载的现象。

这样是不是就只能解释为因很多lun 的iops增加，导致sp UT升高，从而影响了存储整体性能。   纠结啊，8000的iops  就把存储干掉了啊...

1. 如果UT都达到85%，那存储本身有overload的嫌疑，但你前面说一共也只有160MB/s的带宽，照理这点I/O不会造成这么大的CPU UT，我觉得你有必要开个CASE看看是否有个别进程hung在那里了，这就不是I/O造成的高CPU了，这可能需要reboot来解决

2. 180 IOPS这些只是参考，对应随机小I/O，所以不能认为小于180就没有过载，你要看看disk的响应是多少

8000 IOPS不太可能把CX4-480逼上绝路的，最好还是找EMC支持看看NAR File找原因，猜是没有意义的。

客气了，多来论坛讨论讨论啊，互相学习。

再推荐你看个帖子：https://community.emc.com/thread/148915

受教了，多谢啊。