工程师笔记｜其他正常，唯独顺序写性能很低，怎么回事？

前言

本文根据Dell EMC工程师处理客户硬盘写性能差问题的实践，详细重现了从发现问题、排查原因到解决问题的整个过程，提供了多种解决思路，并归纳了修改IO调度配置的两种方法，供相关人员参考。

一发现问题：

某汽车交易网站在戴尔易安信R640服务器上测试Intel S4500 SSD时，遇到了随机读、写和顺序读性能都很高，但顺序写性能低的问题，主要表现在IOPS、BW等指标与其他结果相差10倍。

>>>>R640硬件配置：

两颗4110 CPU、4条16G内存、4块600G SAS 10K+2块480G SSD、H730P RAID卡、i350网络子卡、495W冗电。客户安装的OS版本：CentOS 7.4。

赶到客户现场后，我们按照客户提供的FIO脚本进行测试，重现了客户所说的IO写性能低的问题。

二解决过程：

滑动查看

1. 更新测试脚本：降低numjobs值后：IOPS=45.2k, BW=177MiB/s，但是，客户不接受！

2. 调整BIOS模式：max performance, 问题没有解决；

3. 升级BIOS、RAID卡FW：问题没有解决；

4. 将Intel S4500 480G SSD换到R630上，测试结果达到240MB/s；怀疑H730P RAID卡问题；

5. 更换H730P RAID卡，问题依旧没有解决；

6. 设置RAID 0模式，以及 Non-RAID模式，问题依旧没有解决；

7. 更换测试软件FIO的版本：3.1、3.3、3.6，问题依旧没有解决；

8. 更换RAID卡驱动，从Broadcom官网下载最新的驱动：问

9. 更换OS：安装CentOS 6.9，问题解决！

10.调整CentOS 7.4的I/O调度，问题解决！

三原因分析：

通过本次测试，我们发现CentOS 7.4 默认的I/O调度是Deadline（倒计时）算法，而CentOS 6.9下默认支持的是CFQ（完全公平算法）。

>>>>cfq（完全公平算法）:

CFQ算法，给每个进程一个IO队列，然后轮询各个队列，达到公平的效果。适用于传统硬盘，也是长久以来的默认算法。为减少寻址，该算法尝试给IO排序，极端情况可导致IO饥饿，即如果一个程序有大量顺序读写，那么它就会插队，导致其他程序IO饥饿。CentOS 6默认使用CFQ算法。

>>>>deadline （倒计时算法）:

Deadline算法，维护读写两个队列，每个队列都有各自的超时时间，确保每个IO在一定时间内可以得到满足，能有效防止IO饥饿，适用于传统硬盘。Ubuntu以及CentOS 7 都默认使用Deadline算法。

针对本案例，将I/O调度设置为CFQ后，写性能正常！

四情景复现：

该汽车交易网站在R640上测试Intel S4500 SSD时，遇到了随机读、随机写、顺序读性能都很高，但顺序写性能低的问题，主要表现在的IOPS、BW等指标与其他结果相差10倍。

第一天，我们在客户现场确认环境后，按照提供的FIO脚本进行测试，重现了IO写性能低的问题。初步测试结果为IOPS=8104, BW=31.7MiB/s。

此后根据以往的FIO调试方法，我们减少了numjobs值，性能达到约IOPS=45.2k,BW=177MiB/s，此时numjobs=4。由于某竞争对手公司的测试脚本在numjobs=50下能够测到此数量级，客户较倾向于使用50 numjobs，要求重新测试50 numjobs的结果，但是R640在此压力下仍然只测到了几十兆的带宽水平。

我们又建议客户使用numjobs=4测试了某公司的服务器，测试结果为IOPS=32k,BW=129MiB/s，IOPS仍高于R640。

第二天，由于现场测试机的固件并非最新，我们优先更新了固件的版本，主要更新了BIOS固件版本到1.3.7，H730P卡的固件更新到了25.5.4.0006_A12，但这并未引起性能提升。因此我们考虑更换RAID来验证硬件是否存在问题。

第三天，到达客户机房后，我们更换了H730P卡，并重装了操作系统，然后立即对系统进行测试，结果仍然没有性能提高，因此我们决定将SSD盘拿回公司再测试。

我们将SSD放入了公司的一台R640上，安装了与客户一致的CentOS 7.4版本，也使用了同样的脚本，中间只修改设备名称而保持其他参数不变，测试结果并没有改善。

后来我们将SSD放入另一台操作系统为redhat6.9的740xd上进行测试，结果性能达到了200MB+/s，因此初步推断为不同的操作系统影响了SSD的顺序写性能。

对比两台服务器的配置，除硬件不同外，安装配置也不一样，主要是OS盘的配置方式、操作系统版本等不同。

我们将R640保持到与740xd一致的安装方式、配置，也重装了最新的操作系统，测试后问题依旧，由此证明IO性能低的问题与系统安装方式、OS盘配置无关。

➤ 另外，我们也将驱动升级到最新的megaraid_sas-07.705.02.00_el7.4-1.x86_64，结果证明与驱动关系不大。当然我们也考虑到是否是某一版本的驱动性能较好造成的，但客户服务器上的驱动也不是最新版本，加上CentOS自带的驱动与更新过的驱动，关于驱动我们已经测试了三个版本。

排除了主要影响因素，我们考虑直接将R640安装为Red Hat 6.9来确认性能差异是否是操作系统版本不同导致的。

安装过程除了操作系统盘为RAID1的VD，S4500 SSD为non-raid配置外，其他配置均为系统默认，除了BIOS的配置只调整为Max Performance Red Hat6.9安装完成后，我们直接测试FIO，结果达到了平均IOPS=60k, BW=236MiB/s，由此可以断定是操作系统的问题。

此后我们使用最小化方式在R640上重装了CentOS 7.4的操作系统，除了编译FIO需要的相关依赖包外，没有安装任何其他程序，也未升级任何驱动。

经研究发现，Red Hat 7.4的IO调度配置为Deadline，这是它与Red Hat6.9版本在IO方面的主要不同点，考虑到可能不同的硬件需要配置不同的调度，于是我们对三种调度都进行了测试，结果只有CFQ的顺序写性能正常，其余均相差10倍

配置为CFQ的顺序写：

配置为Deadline的顺序写：

配置为Noop的顺序写：

>>>>修改IO调度配置的二种方法

方法一：

① 找到/etc目录下的grub2-efi.cfg文件，如果boot mode为BIOS，则找到grub2.cfg文件

② 找到引导操作系统的字段一行，在后面添加elevator=cfq，保存

③ 重新启动后生效。

方法二：

① 直接使用echo命令修改对应SSD设备的scheduler值

[root@localhost ~]# echo "cfq" > /sys/block/sdb/queue/scheduler

② 使用cat命令查看，即时生效，重启后恢复原始配置

[root@localhost ~]# cat /sys/block/sdb/queue/scheduler

noop deadline [cfq]

FIO脚本:

fio -filename=/dev/sda -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=4k -size=1000G -numjobs=1 -runtime=180 -group_reporting -name=sqe_100write_4k

Kernel版本：

Linux g1-net-test-04 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux