实在抱歉，我们太懒了，该站点停止文章更新了~

大家都知道SSD成本比较高，而不少用户在考虑可用性时都会选用RAID 10作阵列，这样无疑又增加了成本。然而RAID 10的可用性也并非百分百完美。为了能够平衡可用性和成本，因此最近一直在研究性价比更高的RAID 50，它提供了接近RAID 10的可用性并且接近RAID 5的成本，像是在高可用的RAID 10和低成本的RAID 5之间的取了一个平衡点。

为了能够直观了解不同RAID类型下的故障可用性，我们首先做个简单的可用性分析（以8盘RAID 10的同等容量作对比）：

RAID 50中：4块盘组成单组RAID 5，然后两组RAID 5再组成RAID 0最后得到8块盘的RAID 50

案例分析：

• 第1块盘的容错概率都是100%，可见磁盘阵列最基本的能力就是容错，然而不同级别的阵列能够提供的数据保护能力也是不同的；
• 从第2块盘开始除了RAID 6能够提供100%的故障可用性以外，其他包括RAID 10在内都不能提供完美的解决方案。同时我们可以发现RAID 5的容错能力是四者中最差的，但是要达到同样容量所需要的盘数量也是最少的，如果故障运维较为及时的话RAID 5是一个性价比较高的方案，不然在第一块盘故障后至阵列修复期间如果发生第二块盘故障就会导整个阵列故障（数据全部丢失），这就是风险所在；
• RAID 6当然是较为可靠的方案，但是它要牺牲两块盘的容量并且性能也较差（后面有性能测试说明），所以要权衡性能和可用性；
• 当然重点还是RAID 10和50：我们发现50在第二块盘故障时的可用概率和10比较接近，由于上述案例中只有两组RAID 5因此只能提供至最多两块盘的容错，如果RAID 5的组数量更多的话能够容错的盘数也将更多，且可用概率也会更高。

我们以9块盘RAID 50（3组RAID 5）为例作分析（达到相同容量的RAID 10需要12块盘）：

再以12块盘RAID 50（4组RAID 5）为例作分析（达到相同容量的RAID 10需要16块盘）：

上面对比中RAID  50已经能够容忍第3甚至第4块盘的故障，只是可用性相比RAID 10低了些，但是两者都不能达到完美的100%，所以权衡可用性和成本RAID 50还是有相当大的优势。

接下来看看性能，为了能够很好地分析性能，我们沿用了第一组对比方案的作性能分析：

 随机读分析：

• 理论上认为R10性能最好，真实测试数据显示4K、8K数据块下R5、R50、R6的性能都要优于R10；
• 当数据块增大到16K、32K时，R10的多盘优势才被逐渐体现出来。

随机写分析：

• 4K由于R50、R5由于有大量校验计算一定程度上影响了性能，但随着数据块逐渐增大，盘数量的优势也显现出来。当数据块达到和超过8K时，R50性能全面超越了R10；
• R10由于存在R1的写同步问题，因此只有4块盘在支撑并发写，随着数据块的增大，R50和R5的多盘性能优势开始发挥。

混合随机读写分析：

• 得益多盘和无校验计算，混合读写R10领先；R50其次，和R10相差27%，性能也较为接近，R5和R50性能为线性关系，R6性能最差。

顺序读分析：

• 由于不存在校验计算，顺序读性能基本上由盘的数量决定；R50和R10性能也较为接近，同盘数的R6和R50性能相当，而盘数较少的R5性能相对前三者要弱一些，符合预期。至于为何R10性能无法线性增加，主要是因为阵列卡本身的性能限制。

顺序写分析：

• 顺序写R5被优化得最好；R50由于需要同时计算两次校验因此损失了一些性能，和R10性能相当，当数据块达到512K时，多盘优势进一步体现出来了，拉开了与R10的差距；R6由于校验和计算的实现较为复杂，顺序写性能也是最差的。

再来看看这些阵列方案的性能和容错特性：

性能测试结论：

• 性能测试显示，相同容量的R50和R10性能接近：其中小块文件的随机读R50要全面好于R10，随机写4K虽然R50和R10差距在28%，但是块增大后R50要全面优于R10。顺序读写方面，R50和R10十分接近。
• 容错方面，R50接近R10：第二块盘容错率R50十分接近R10，两者相差30%。R10的优势主要是在有一定的概率提供第三、甚至第四块磁盘的容错率，但是考虑到并非100%容错，因此从容错角度来看R50虽然和R10有一些差距，但也已体现出较好的容错率，至少优于R5。而且R50搭配灵活，甚至可以指定3组R5以达到最大3块磁盘的容错；
• 成本方面，R50有很大优势：按这个配置计算R50只有R10的3/4。

总结：

RAID 50提供了接近RAID 10性能、可用性以及接近RAID 5成本的特性，具有较好的整体性价比优势，所以考虑使用RAID 50替换RAID 10把！

没有开场白，直接切主题！各位把这篇当成是报告来阅读吧：

应用IO模型：大量读线程同时访问多块SSD，请求均为4KB随机读，并且被请求的数据有一定间隔连续性；

服务器硬件配置：LSI SAS 2308直连卡 + 8块SSD

优化前应用QPS：27K

第一轮优化：读策略优化

通过 /sys/block/sdx/queue/read_ahead_kb 观察到预读大小为128KB，进一步观察iostat情况：

观察到每块SSD的rMB/s十分高，平均已经达到了250MB/s+，初步判断是由于read_ahead_kb的设置影响了应用的读效率（即预先读取了过多不必要的数据）。遂将read_ahead_kb设置为0，观察iostat情况如下：

而应用QPS却下降至25K！

分析原因：由于之前有预读功能存在，因此部分数据已经被预先读取而减轻了SSD的访问压力。将read_ahead_kb设置为0后，所有的读访问均通过随机读实现，一定程度上加重了SSD的访问压力（可以观察到之前%util大约在60~80%之间波动，而预读改成0之后%util则在80~90%之间波动）

尝试16K预读

通过IO模型了解到每次请求的数据大小为4KB，因此将read_ahead_kb设置为16KB进行尝试，结果QPS由25K猛增到34K！

观察iostat情况如下：

%util降了不少，而且通过rrqm/s可以发现出现了一部分读合并的请求，这说明优化确有成效。

此时CPU_WA也由原来的平均30%下降到20%，这说明处理器等待IO的时间减少了，进一步验证了IO优化的有效性。

第二轮优化：直连卡中断多核绑定

考虑到SSD的随机读写能力较强（通过上面的iostat可以发现），在多盘环境下每秒产生的IO请求数也已接近100K，了解到LSI SAS 2308芯片的IOPs处理极限大约在250K左右，因此判断直连卡控制芯片本身并不存在瓶颈。

其实我们担心更多的是如此大量的IO请求数必定会产生庞大数量的中断请求，如果中断请求全部落在处理器的一个核心上，可能会对单核造成较高的压力，甚至将单核压力打死。因此单核的中断请求的处理能力就有可能成为整个IO系统的瓶颈所在，于是我们通过mpstat观察每个核心上的中断数：

可以发现第二个核心中断数已经达到了十分恐怖的80K！再来观察实际的处理器核心压力情况，为了能够更加直观地了解，我们用了比较准确的i7z工具来观察：

果然不出所料，Core 1的Halt（idle）已经到了1，充分说明第二个核心确实已经满载。

那么通过观察/proc/interrupt的情况再来进一步验证我们的假设，：

我们截取了片段，可以发现mpt2sas0-misx的大部分压力都集中在了CPU 1上，并且我们发现直连卡模式是支持多队列的（注意观察irq号从107至122，mpt2sas驱动总共有16个中断号），因此我们将实际在处理中断的irq号107至118分别绑定至不同的核心上（这里就不再赘述有关多核绑定的原理，有兴趣的同学可以百度搜索以上命令的含义）：

随后我们惊奇地观察到应用的QPS由34K再次猛增至39K！

通过观察mpstat发现大量的中断被平均分散到了不同的处理器核心上：

并且CPU_WA也由平均20%下降到15%，io wait被进一步优化！

优化总结：

• 通过以上两个优化方法将应用的QPS由27K优化至39K，并且处理器的iowait由30%下降至15%，优化收效显著；
• SSD的优化要根据实际的应用IO模型和设备的理论极限值进行综合考虑，同时还要考虑到各个层面的瓶颈（包括内核、IO策略、磁盘接口速率、连接控制芯片等）。

这里我们不再赘述有关寄存器、ALC等处理器架构和原理知识。我们只从直观的数据去分析和了解我们正在使用的多核处理器的真实性能——正所谓“是骡子是马拉出来溜溜”。一切建立在实际运行的数据才是真正有价值的评判依据。

在开始数据分析之前，我们必须弄清楚处理器的计算能力到底是什么：是频率决定了性能？还是核数决定了性能？

首选我们必须了解处理器的一个简单的性能计算公式：

整体性能 = 单核性能 × 核心数

其次性能受哪些因素影响会有以下这些原则：

原则一：架构越新，单核计算性能越强！

对比同频率、同核心数的前后两代处理器的计算能力就能发现架构越新的处理器整体计算能力也越强，这也意味着处理器架构的改进确实提高了单核性能。

原则二：频率越高，单核计算性能越强！

对比同代同核心数不同频率的处理器就能发现频率越高的处理器计算性能也越好，但这并非完全的线性增长。原因是处理器频率上去以后由于受到内存访问速度的限制也会有一定的瓶颈，而频率越高的处理器耗费在数据等待上的时钟周期也越多。

原则三：核心数越多，整体计算性能越强！

对比同代同频率不同核心数的处理器不难发现核心数越多的处理器整体计算性能也越好。但是如果观察单核性能会发现其实核数越多的处理器单核性能比同频率核数较少的处理器会差一些，主要原因是核数越多对共享资源的争抢概率也越高，这些共享资源包括L3缓存、内存、QPI总线等，这也就是多核处理器总是要把L3缓存做得很大的原因，核数越多L3缓存也越大。

请重点区别单核性能和整体性能：

1、单核性能：它影响的是单线程或者单任务的计算能力（即计算的响应延迟），对于单个请求计算的响应延迟要求较高的应用，就要用高频处理器去满足，而不是用多核。因为应用的一个线程无论任何时候都只能运行在处理器的一个核心上，增加核心数量对于改善单个计算请求的响应延迟并没有帮助，也就是说对跑单线程、单任务的应用无法提升其性能；

2、整体性能：前面提到核数越多整体性能越好，这也意味着多线程和多任务的应用环境下，如果要提高单机的计算处理量最好的办法是增加核心数而不是靠提高频率。理由很简单，核数较少的处理器晶元面积也小。如果要一味提高性能便要提高频率，提高频率其实就是给处理器晶元加电压。晶元能够忍受的电压是有限的，电压耐受力越高的晶元成本也越高。因此从稳定性和成本去考虑的话，晶元面积更大的多核处理器才是提高整体计算能力的最好选择。

下面我们挑选几款主流的双路处理器来作性能分析：

主题1：核数相同、频率不同

数据说明：如下表所示从第7行（Geekbench Integer）起是各项性能指标：分别是Geekbench整数成绩、SuperPI运行百万次的时间、以及根据Geekbench整数性能分别除以“处理器数量”、“核心数量”、“核心数量和Ghz的乘积”等来分别针对整体性能，单核计算能力，单个处理器、单个核心以及单个核心下每个Ghz的性能进行分析评估。

数据分析：

1、SuperPI体现的是单核浮点性能，通过SuperPI成绩可以发现处理器频率越高单核计算性能也越好，这一点也可以通过“性能/每个核心”项目体现，频率越高单核的计算性能也越好；

2、Geekbench Integer评估的是处理器的整体性能，规律自然也是频率越高整体性能越好；

3、“性能/每Ghz/每个核心”项目评估的是处理器的计算效率，这个项目是将Geekbench的整数成绩按照核数拆分并根据单个Ghz去计算，可以发现核数相同的处理器这个数据相互比较接近。

主题2：频率相同、核数不同

数据分析：

1、SuperPI项目更加可以说明单核计算能力受频率的影响，虽然2640 v2有8个核心，但对SuperPI的成绩没有丝毫帮助；

2、通过“性能/每个核心”项目可以发现，同频率下核数更少的2620 v2在这项成绩略好一些，即频率相同核数较少的处理器在单核性能上总是会核数更多的处理器略好一些，这确实也验证了核心之间存在资源争抢的假设；

3、Geekbench Integer成绩也体现出多核的性能优势，同频率下核数较多的处理器整体性能也更好；

4、再来看看用以评估计算效率的“性能/每Ghz/每个核心”项目，可以发现核数较多的处理器在计算效率上处于劣势：八核处理器的单核Ghz性能明显要比六核处理器的低不少，这样也进一步验证了核心之间存在资源争抢的假设，并且核数越多资源争抢的现象也越显著。

主题3：整体性能相同

最后一组选取整体性能接近而频率和核数均不同的处理器

数据分析：

1、SuperPI的成绩依旧验证了单核性能只受频率影响的假设；

2、Geekbench Integer成绩说明2630 v2的性能整体略好于2640 v2；

3、通过“性能/每个核心”项依旧验证了频率决定了单核性能的假设；

根据以上数据我们可以进一步将计算公式细化为：

多核处理器的整体计算能力 = 单核Ghz计算能力 × 频率数 × 核数

结论：

1、处理器整体性能和频率、核数有关，但并非核数越多性能就一定越好，高频少核和低频多核整体性能很可能接近；

2、核数决定了计算承载能力，核数越多能够承载的计算量也越大；

3、频率决定了单核计算能力，频率越高单个计算请求的响应延迟也越低；

4、频率相同的情况下，核数越多单核计算效率也越低；