某生产业务系统闪存优化前后性能对比分析报告（二）

前言

在之前的某生产业务系统闪存优化前后性能对比分析报告（一）附带上线前测试报告一文中，详细介绍了某业务系统，在闪存优化前和优化后的性能分析与对比，然而在对比过程中发现该业务系统数据库的存储卷的写IO平均响应时间存在许多毛刺现象，并且该存储卷所对应的SVC NODE的写响应时间也在大概1点左右，出现高峰，如下图所示，今天就来对这些毛刺和高峰现象进行一一解剖。

Volume写IO平均响应时间（取样时间为9月11日至9月15日）

SVC NODE写IO峰值响应时间（取样时间为9月11日至9月15日）

问题分析

问题一：SVC Volume CREDIT_WASDB_DATA03在某些时刻会显示较高的Write Response Time（毛刺）。
分析：从图一中很明显可以看到，写IO的日间平均在1 ms左右，而且晚间有很多毛刺，晚间会飙升至几十ms，集中在每日0点之前和0点之后。理论上在SVC缓存没有写满之前，主机对SVC节点的写操作，会先写该SVC节点的缓存，然后再将缓存同步至同一IO GROUP的的另一SVC节点，同步完成后，会直接告诉主机写IO已完成，不会等待IO物理落盘，这也就合理解释了为什么日间的写IO平均响应时间才1ms的原因，然而毛刺现象告诉我们，这时的SVC写缓存应该是满了，需要等待IO物理落盘，而物理落盘的时间又由FS900和DS8870中稍慢者决定的，因此造成了写IO响应时间飙升，但是事实果真如此吗？我们找到图中蓝色线代表的SVC Volume CREDIT_WASDB_DATA03，进一步分析，如下图，在9月18日4:20，Volume的Write Response Time为27.25 ms。确实较白天高了许多。

于是我们查看了该Volume在4:20的IOPS（IO Per Second），如图所示，很惊讶的注意到该Volume的IOPS却极小，为0.19。

按照TPC（IBM Specturm Control）的Response Time是用公式:

Response Time=总Response Time/总IOPS 

计算出来的，因此，当IOPS极小时，Response Time的图形就会失真，造成了所谓的毛刺现象，所以为了检验毛刺是否失真，我们需要同时查看对应的IOPS，当Response Time在IOPS越大时越可靠。通常，IOPS在大于100时较可靠。为了确认此性能问题确实为误报，我们查看了此一时刻后端存储的性能数据。
如图显示，此Volume在Flash900上。

在9月18日4:20，Flash900对应的Pool的Write Response Time只有1.3ms

因此，Flash900性能正常，此性能问题为误报，可以忽略。
问题二：SVC Node1在某些时刻（每日凌晨1点左右）会显示较高的Write Response Time（高峰）。
分析：如下图，在9月18日1:10，Node1的Write Response Time为16ms。

我们逐一查看9月18日1:10的后端mdisk性能数据，发现有一台DS8870所属的mdisk 的Write Response Time较高。如下图所示, mdisk PowerVC_DS8870_3003_V007达到16ms

我们用TPC查看这台DS8870 DS8870_JY的性能数据，对应的Volume名称为NOT SET (ID:3003)。在1:10时刻，Write Response Time为16，确实较高

一般而言，对非SSD存储，Volume Response Time小于7ms为优异，介于7ms和15ms之间是正常。此Volume的16ms为临界值，暗示后端Array可能接近满负载。要找到问题的原因，需要分析这个Volume所在的Array性能数据。如图，Volume所在的Pool为RAID5_Pool1, 包含有奇数结尾的Array：

我们选取其中一个Array A9，仔细研究其性能数据。
如图所示，此Array在1:10时刻Write Response Time较高，接近70ms。

通常，正常的Array Response Time会小于60ms。当超过60ms, 即便前端有cache，Volume性能也会下降。

上图显示，问题发生时，Array A9的Read IO接近900，Write IO为100。
下面两张图，显示A9为Raid5, 10K RPM（转速）的Array。


由于一块10K RPM Disk的IOPS设计阀值为140。该Array由7块Disk组成，那么Raid 5的Array IOPS设计阀值为7140=980，由于Raid 5有写惩罚效应，A9的实际IOPS为 Read IO+3Write IO=900+300=1200。
综上，A9的实际IOPS大于设计阀值，导致较高的Response Time。
那么，是哪个应用贡献了最多的IOPS呢？我们将这一时刻，作用在RAID5_Pool1 里的Volume IO排序，发现volume-YX_ECMGPFS_vdisk06等IOPS最高。

由于该Volume的上端主机为影像应用，即带宽型应用，在每日1：10左右的时候存在大量的影像数据读写，对写响应时间要求不高，故该问题属于正常现象。

最终结论

在仔细的分析性能数据后，我们对两个疑似性能问题有如下结论。
问题一：SVC Volume CREDIT_WASDB_DATA03在某些时刻会显示较高的Write Response Time（毛刺）。
结论: TPC的Response Time是用公式 总Response Time/总IOPS计算出来的，因此，当IOPS极小时，Response Time会失真。此问题出现时，Write IOPS仅为0.19，因而算出一个较高的Write Response Time。因此，此Volume所在的Flash900性能正常，此性能问题为误报，可以忽略。

问题二：SVC Node1在某些时刻会显示较高的Write Response Time（高峰）。
结论：每天凌晨1点左右，影像应用，即带宽型应用，开始上传数据。由于IOPS较高，导致DS8870后端Array的IOPS大于设计阀值，Write Response Time增高。所以SVC的Node会显示较高的Write Response Time。对于带宽型应用，更看重带宽，IO的反应时间影响不大。如果前端应用没有明显症状，可依旧保持观察。