某生产业务系统闪存优化前后性能对比分析报告（一）附带上线前测试报告

整体架构：

近期我行生产XX业务系统数据库的主存储切换到了全闪存阵列（IBM FS900），用来提升数据的访问效率，用底层的方式解决一些燃眉之急的问题。闪存阵列上线后，经过对底层存储性能的深入分析，有了一些初步的结论，在此报告如下：
XX系统闪存优化前的系统整体架构如下图所示：

其中XX交易类WAS应用集群和XX管理类WAS应用集群读写访问DB2数据库主节点，XX统计查询类WAS应用集群访问另一DB2数据库备节点，该DB2数据库主节点通过DB2 HADR的Near Sync将数据同步至另一DB2数据库备节点，将统计查询业务和交易、管理类业务读写分离。生产站点的两个主数据库节点和同城站点的数据库节点搭建了Power HACMP XD高可用架构，生产和同城的底层存储采用了两套SVC Cluster，通过Metrol Mirror保持同步复制。生产SVC Cluster的两套后端存储为DS8870和V7000，通过VDISK Mirror镜像保持同步，同城SVC Cluster的后端存储为DS8870。整个架构冗余度高，可靠性高，并且通过读写分离，保证了一定的性能。但是随着XX业务的发展，有两个突出的问题亟需解决，一是晚间批量时间过长，导致晚间的可维护时间窗口短；二是季度结息期间数据库压力较大，交易和查询性能不足，容易导致前端WAS Web Container线程池撑满。为了缓解该问题，在本季度结息前，将XX的V7000存储Mdisk从SVC VDM镜像中拆除，DS8870和FS900全闪重新做SVC VDM，并在业务低峰期，将XXSVC Vdisk的主Copy和备Copy关系反转，由FS900提供全部的读IO，切换后的整体架构如下图所示：

性能指标的选取：

关于存储性能的指标有很多，如读写吞吐量、读写IOPS、读写IO大小、读写平均响应时间和读写峰值响应时间，由于XX业务的应用模型没变，之前每天的吞吐量、IOPS、IO SIZE等趋势基本是固定的，切换至闪存阵列后，这些指标的值也是相同的（下图所示），因此单个卷的这些性能指标在没有瓶颈的情况下，不需要过多关心，所以这里重点关注的指标只有读写平均响应时间和读写峰值响应时间，下面一一分析。

注：从图中可见，14号晚18:00上了闪存阵列后，IOPS的规律依旧和之前类似。

性能分析：

本次闪存切换具体实施时间为9月14日晚18:00，经过一天SVC的性能数据的收集，对比之前的性能数据，分析如下：
（1）读IO平均响应时间（取样时间为9月11日至9月15日）图：

分析：上图中的时间轴上的12/13/14/15为日期起点，也就是0点，通过该图可发现，上了闪存后，读IO的平均响应时间确实降低了许多，光凭肉眼只是感觉上闪存之前平均应该在8-10 ms，上闪存之后平均应该在2-3 ms左右，看起来只有4倍读IO平均响应时间的提升，但是肉眼一般是不准确的。
于是抽取了两天的读IO平均响应时间对比：
9月7日18:00至9月8日11点：

9月14日18:00至9月15日11点：

前者大致在8ms，后者大致在1ms，大概有8倍的提升。
（2）读IO峰值响应时间（取样时间为9月11日至9月15日）：

分析：同样对比上闪存之前的读IO峰值响应时间和上闪存之后的读IO峰值响应时间，凭肉眼发现确实有了很大的提升，前者均值应该在400 ms左右，后者应该在50 ms左右，像是提升了8倍，但真实数字需要进一步确定。
同样抽取了两天的最大读IO平均响应对比：
9月7日18:00至9月8日11点：

9月14日18:00至9月15日11点：

看起来前者平均在400 ms，后者平均在50 ms，同样感觉像是提升了8倍。
（3）写IO平均响应时间（取样时间为9月11日至9月15日）图：

分析：写IO就大不一样了，日间平均在1 ms左右，而且晚间有很多毛刺，晚间会飙升至几十ms，集中在每日0点之前，是否是XX批量作业导致的呢？理论上在SVC缓存没有写满之前，主机对SVC的写操作，写完SVC缓存，同步缓存后，会直接告诉主机写IO完成，不会等待IO物理落盘，如下图所示，这也就合理解释了为什么日间的写IO平均响应时间才1ms的原因，然而毛刺现象告诉我们，这时的SVC写缓存肯定是满了，需要等待IO物理落盘，而物理落盘的时间又由FS900和DS8870中稍慢者决定的，因此造成了写IO响应时间飙升。由于当时SVC写缓存被写满，可以肯定的是，当时的IO吞吐量一定很高，究竟XX的IO吞吐量高，还是其他系统对SVC同一IO Group node的大量写IO导致的，需要进一步分析。

于是查看了所有XXVolume的写吞吐量，看下有什么线索：

很惊奇的发现，上闪存之后，名为CREDIT_WASDB_DATA03的Volume（蓝色的线）有过一段时间写响应时间很高，但是写吞吐量却非常低，这就非常明显的指明了当时一定是CREDIT_WASDB_DATA03的SVC Prefer Node的写缓存肯定是满了，要么IOPS很高，要么吞吐量很高，需要从整个SVC层面继续深入分析，这个下个部分再出报告。
我们接着分析，为了具体分析，到底上了闪存之后，读写IO响应时间的提升量，进行了同日对比和近期对比，如下：
（4）9月8日（上周四）读写IO响应时间（日间08:30-15：30）：

分析：日间平均读IO响应时间（7.64+6.18+8.34+6.46）/4=7.145 ms，最大平均读IO响应时间（10.46+8.99+12.84+7.66）/4=9.988 ms，每天日间写IO都类似，忽略。
（5）9月13日读写IO响应时间（日间08:30-15：30）：

分析：日间平均读IO响应时间（7.67+6.54+8.73+6.06）/4=7.25 ms，最大平均读IO响应时间（11.32+8.90+11.24+7.77）/4=9.81 ms
（6）9月14日读写IO响应时间（日间08:30-15：30）：

分析：日间平均读IO响应时间（8.10+7.05+8.75+6.20）/4=7.53 ms，最大平均读IO响应时间（15.31+9.43+12.42+7.82）/4=11.25 ms
（7）9月15日切闪存后，读写IO响应时间（日间08:30-15：30）：

分析：日间平均读IO响应时间（0.67+0.97+1.25+1.34）/4=1.06ms，最大平均读IO响应时间（1.02+1.48+2.17+2.91）/4=1.895 ms，可见切闪存后，平均读IO响应时间1.06 ms，较前面3天的平均值（7.145+7.25+7.53）/3=7.31 ms，提升了690%；最大平均读IO响应时间1.895 ms，较前面3天的平均值（9.988+9.81+11.25）/3=10.35 ms，提升了546%。
（8）对比日间，DB2数据库SQL耗时。
闪存上线前，打开数据库SQL性能监视，摘取一段时间内，SQL语句耗时排序，这些SQL语句大多数为查询语句：

Elapsed Execution Time:  36.817335 seconds
Elapsed Execution Time:  29.776199 seconds
Elapsed Execution Time:  10.132657 seconds
Elapsed Execution Time:  8.178850 seconds
Elapsed Execution Time:  8.094183 seconds
Elapsed Execution Time:  8.054993 seconds
Elapsed Execution Time:  7.077847 seconds
Elapsed Execution Time:  7.032088 seconds
Elapsed Execution Time:  6.610400 seconds
Elapsed Execution Time:  6.574136 seconds
Elapsed Execution Time:  5.539895 seconds
Elapsed Execution Time:  4.062694 seconds
Elapsed Execution Time:  3.666758 seconds
Elapsed Execution Time:  3.608192 seconds
Elapsed Execution Time:  3.257147 seconds
Elapsed Execution Time:  3.206806 seconds
Elapsed Execution Time:  3.148031 seconds
Elapsed Execution Time:  3.103065 seconds
Elapsed Execution Time:  3.081526 seconds
Elapsed Execution Time:  2.659606 seconds
Elapsed Execution Time:  2.601101 seconds
Elapsed Execution Time:  2.539749 seconds
Elapsed Execution Time:  2.448799 seconds
Elapsed Execution Time:  2.383544 seconds
Elapsed Execution Time:  2.330721 seconds
Elapsed Execution Time:  2.316523 seconds
Elapsed Execution Time:  2.245110 seconds
Elapsed Execution Time:  2.212562 seconds
Elapsed Execution Time:  2.166946 seconds
Elapsed Execution Time:  2.113934 seconds
Elapsed Execution Time:  2.113283 seconds
Elapsed Execution Time:  2.084432 seconds

闪存上线后，通过以下语句获得一段时间内的SQL语句耗时情况：

db2 "select total_act_time/num_executions as act_time,num_executions,total_act_wait_time/num_executions as wait_time,pool_read_time/num_executions as
pool_read_time,total_extended_latch_wait_time/num_executions as latch_time,prep_time/num_executions as prep_time,pool_data_l_reads,pool_data_p_reads,substr(stmt_text,1,400) from
table(mon_get_pkg_cache_stmt(null,null,null,-2)) where num_executions> 0 order by 1 desc" 

很明显发现，闪存优化后，最高SQL耗时降到了3秒，执行次数较多的语句耗时也才200ms了，确实有了长足的提升。

最后结论：

1.通过SVC+FS900+DS8870和SVC+DS8870+V7000架构的对比，从存储底层分析，读响应时间有了7倍左右的提升，从数据库层分析，查询的SQL语句有了8倍甚至10倍左右的提升。
2.对于写操作来说，由于SVC的存储，在SVC NODE的写缓存充足的情况下，写响应时间维持在1 ms左右，性能非常好；在SVC NODE的写缓存被写满（该NODE的IOPS或者吞吐量较高）的情况下，写操作需要等待其他缓存中的数据刷入至后端存储，由于FS900和DS8870做了VDM镜像保护，缓存刷入需要等待两个后端存储都写完成，才会回写完成响应，因此写响应时间取决于较慢的存储，这样会造成写操作的响应时间激增，形成毛刺现象。这点需要从整个SVC的角度进一步深入分析，后面会出相应的报告。
3.对于日间XX业务来说，SVC NODE的写缓存充足，写操作性能非常好，通过闪存的优化，大幅度提升了读操作的性能；对于晚间XX批量业务来说，由于批量基本上是写操作，再加当时SVC NODE的压力较大，写响应时间较长，所以闪存并没有优化晚间XX批量的批量时间，这一点需要进一步通过分析，提出改进方案。

---

最后附上闪存上线前测试报告：

表格：
SVC+FlashSystem840，裸设备，16个100GB的卷，每台测试机8个卷。

数据块	读写方式	IOPS	带宽(MB/S)	响应时间(ms)
4KB	100%随机读	307135.53	1199.75	0.831
4KB	100%随机写	293871.81	1147.94	0.868
4KB	70%随机读，30%随机写	299106.01	1168.38	0.853
4KB	100%顺序读	309636.30	1209.52	0.823
4KB	100%顺序写	240655.33	940.06	1.060
4KB	70%顺序读，30%顺序写	275673.79	1076.85	0.925
8KB	100%随机读	280077.73	2188.11	0.911
8KB	100%随机写	250746.46	1958.96	1.017
8KB	70%随机读，30%随机写	257717.95	2013.42	0.990
8KB	100%顺序读	281291.25	2197.59	0.907
8KB	100%顺序写	198524.76	1550.97	1.286
8KB	70%顺序读，30%顺序写	238499.82	1863.28	1.070
32KB	100%随机读	83279.41	2602.48	1.151
32KB	100%随机写	75425.18	2357.04	1.270
32KB	70%随机读，30%随机写	72438.50	2263.70	1.323
32KB	100%顺序读	83470.84	2608.46	1.148
32KB	100%顺序写	59248.31	1851.51	1.618
32KB	70%顺序读，30%顺序写	68515.49	2141.11	1.399

SVC+FlashSystem840，文件系统建在全分配的卷上，16个100GB的卷，每台测试机8个卷，做成一个卷组，建一个文件系统，用dd写0的方式创建8个90GB的文件。

数据块	读写方式	IOPS	带宽(MB/S)	响应时间(ms)
4KB	100%随机读	276371.66	1079.58	0.923
4KB	100%随机写	272044.03	1062.67	0.937
4KB	70%随机读，30%随机写	271772.97	1061.61	0.939
4KB	100%顺序读	202461.21	790.86	1.260
4KB	100%顺序写	140283.49	547.98	1.821
4KB	70%顺序读，30%顺序写	181332.24	708.33	1.408
8KB	100%随机读	260296.38	2033.57	0.980
8KB	100%随机写	241281.62	1885.01	1.057
8KB	70%随机读，30%随机写	240627.34	1879.90	1.061
8KB	100%顺序读	155312.91	1213.38	1.644
8KB	100%顺序写	120563.22	941.90	2.120
8KB	70%顺序读，30%顺序写	169364.68	1323.16	1.507
32KB	100%随机读	78073.30	2439.80	1.228
32KB	100%随机写	73271.21	2289.73	1.308
32KB	70%随机读，30%随机写	70737.81	2210.56	1.354
32KB	100%顺序读	46700.61	1459.39	2.054
32KB	100%顺序写	44937.25	1404.29	2.134
32KB	70%顺序读，30%顺序写	61450.22	1920.32	1.560

SVC+FlashSystem840，文件系统建在瘦供给的卷上，16个100GB的卷，每台测试机8个卷，做成一个卷组，建一个文件系统，用dd写0的方式创建8个90GB的文件。

数据块	读写方式	IOPS	带宽(MB/S)	响应时间(ms)
4KB	100%随机读	280605.31	1096.11	0.909
4KB	100%随机写	8486.06	33.15	30.158
4KB	70%随机读，30%随机写	50753.15	198.25	5.043
4KB	100%顺序读	203419.51	794.61	1.254
4KB	100%顺序写	118898.44	464.45	2.150
4KB	70%顺序读，30%顺序写	166918.43	652.03	1.530
8KB	100%随机读	256682.49	2005.33	0.995
8KB	100%随机写	99529.59	777.57	2.569
8KB	70%随机读，30%随机写	229241.76	1790.95	1.114
8KB	100%顺序读	156888.84	1225.69	1.628
8KB	100%顺序写	118278.94	924.05	2.161
8KB	70%顺序读，30%顺序写	158051.21	1234.78	1.616
32KB	100%随机读	78109.81	2440.93	1.227
32KB	100%随机写	72942.84	2279.46	1.314
32KB	70%随机读，30%随机写	69751.53	2129.74	1.374
32KB	100%顺序读	46667.70	1458.37	2.055
32KB	100%顺序写	44722.32	1397.57	2.145
32KB	70%顺序读，30%顺序写	60905.86	1903.31	1.574

SVC+V7000，文件系统建在全分配的卷上，16个100GB的卷，每台测试机8个卷，做成一个卷组，建一个文件系统，用dd写0的方式创建8个90GB的文件。

数据块	读写方式	IOPS	带宽(MB/S)	响应时间(ms)
4KB	100%随机读	17103.73	66.81	14.966
4KB	100%随机写	7745.03	30.25	33.053
4KB	70%随机读，30%随机写	4214.27	16.46	60.758
4KB	100%顺序读	18857.43	73.66	13.581
4KB	100%顺序写	69348.64	270.89	3.690
4KB	70%顺序读，30%顺序写	32682.85	127.67	7.546
8KB	100%随机读	9441.15	73.76	27.106
8KB	100%随机写	3465.12	27.07	73.923
8KB	70%随机读，30%随机写	4241.86	33.14	60.353
8KB	100%顺序读	58580.37	457.66	4.364
8KB	100%顺序写	64789.00	506.16	3.949
8KB	70%顺序读，30%顺序写	27921.90	218.14	9.163
32KB	100%随机读	7135.91	223.00	13.448
32KB	100%随机写	5505.61	172.05	17.428
32KB	70%随机读，30%随机写	7460.26	233.13	12.899
32KB	100%顺序读	27463.93	858.25	3.493
32KB	100%顺序写	21575.37	674.23	4.447
32KB	70%顺序读，30%顺序写	14354.47	448.58	6.682

SVC+V7000，文件系统建在瘦供给的卷上，16个100GB的卷，每台测试机8个卷，做成一个卷组，建一个文件系统，用dd写0的方式创建8个90GB的文件。

数据块	读写方式	IOPS	带宽(MB/S)	响应时间(ms)
4KB	100%随机读	277098.70	1082.42	0.921
4KB	100%随机写	3272.65	12.78	78.159
4KB	70%随机读，30%随机写	9220.76	36.02	27.767
4KB	100%顺序读	55556.82	217.02	4.604
4KB	100%顺序写	53542.44	209.15	4.780
4KB	70%顺序读，30%顺序写	29044.80	113.46	8.801
8KB	100%随机读	20582.10	160.80	12.433
8KB	100%随机写	2649.57	20.70	97.226
8KB	70%随机读，30%随机写	8783.56	68.62	29.146
8KB	100%顺序读	30024.88	234.57	8.522
8KB	100%顺序写	52062.07	406.73	4.914
8KB	70%顺序读，30%顺序写	18809.67	146.95	13.599
32KB	100%随机读	13613.30	425.42	7.049
32KB	100%随机写	3336.84	104.28	28.764
32KB	70%随机读，30%随机写	10597.74	331.18	9.056
32KB	100%顺序读	14055.40	439.23	6.827
32KB	100%顺序写	20676.08	646.13	4.641
32KB	70%顺序读，30%顺序写	10085.53	315.71	9.516

图形：

**根据性能测试结果可见，IBM FlashSystem 闪存系统具有卓越的性能和极低的响应时间，是客户原有V7000系统性能的10倍以上。由于本次测试环境所限，IBM FlashSystem闪存系统并未测到最大性能值。
AIX JFS2文件系统具有优越的性能，在JFS2文件系统上测得的性能接近裸设备的性能。瘦供给卷的读性能与全分配卷的性能相当，但写性能下降较多。随着瘦供给卷分配的容量上升，写性能也逐步靠近全分配卷的性能。**