raid性能问题和建议 起因 研究这个问题的起因是需要在ESXI机器分配一台高IO的虚拟机做数据库，但实际测试性能完全没有达到测试预期 本想着5块ssd硬盘做raid5，性能肯定没有问题，但分配硬盘后测试发现，4k随机读取iops有500k，符合甚至超出预期，但4k随机写入iops仅11k左右，不仅与我理想中的40k+相差甚远，甚至比我我预期单盘4k随机写入iops（20k）都相差甚远 推测和排查 根据这个结果，我认为是ESXI限制了其性能的发挥，于是找了一些资料，其中可能的问题包括如下： esxi版本比较低，其存储驱动可能有瓶颈 阵列卡驱动可能较低，达到瓶颈 ESXI低版本固有的性能问题 于是我分别从这三个问题入手，尝试升级驱动，也新增了一台高版本ESXI虚拟机（3块SSD硬盘raid5），结果读iops与之前差不多，写iops也与之前差不多，这似乎说明并非ESXI的问题 为了印证不是虚拟化影响的性能，接着我又把ESXI物理机直接更换为centos，跳过所有虚拟化的性能影响，仍保持3块SSD硬盘raid5，结果读写iops与之前仍然相似 至此，问题变成了raid本身的性能问题 RAID级别 我们通常接触的raid级别有raid0、raid1、raid10、raid5、raid6，还有一些更高级的raid50、raid60基本上不太常用，其要求的硬盘位较多，接下来我们从安全性、空间、性能分别分析一下常用的几种raid的特点 raid0 空间：N，raid0拥有最大的空间，他跟jbod有点类似，把所有的硬盘空间叠加 性能：把数据条带化分布到每块硬盘，那么其性能也是最高的，可以是所有硬盘的叠加 安全性：安全性最低，因为所有数据分布在不同硬盘，如果一块硬盘损坏，那么所有数据不可用 raid1 空间：2，raid1因为需要保持镜像，所以空间利用率为50% 性能：写入的时候需要写入两份数据，所以写入性能会下降，读取策略如果每块硬盘都可以参与，那么示有性能提升的 安全性：安全性适中，允许损失一块硬盘 raid10 空间：N/2，可以看做是多块硬盘两两组合成raid1之后再组成raid0，所以空间利用率为50% 性能：写入的时候会先写入两个raid0，再同步两个raid1，理论上是有提升的。读取性能肯定会有提升 安全性：允许两个raid1各丢失一块硬盘，最多丢失两块硬盘，但不能允许单个raid1中丢失两块硬盘 raid5 空间：N-1，数据会被条带化为硬盘数量-1，如果有5块硬盘，那么数据会被条带化为4份数据+1份(条带数据异或)奇偶校验值，如果数据甚至小于条带大小，那么只有第一块硬盘会存储完整数据，其他硬盘则存储填充值 性能：写入的时候需要做奇偶计算，性能有所下降，读取时会分布式读取不同硬盘，性能有所提升 安全：允许丢失任意一块硬盘 raid6 空间：N-2，数据会被条带化为硬盘数量-2，如果有4块硬盘，那么数据会被条带化为2份数据+2份数据的奇偶校验，如果数据甚至小于条带大小，那么只有第一块硬盘会存储完整数据，其他硬盘则存储填充值 性能：写入的时候需要生成两份奇偶计算数据，性能有所下降，读取时会分布式读取不同硬盘，性能有所提升 安全：允许丢失任意两块硬盘（与raid10的差别） 基于以上特性，我们一直使用的 raid5、raid6的模式，因为不挑损坏的硬盘，比如raid10和raid6都是4块硬盘，但raid10不能一组raid1同时损坏，而raid6可以损坏任意两块，在安全性上更高 raid选择 根据数据安全、可用容量、性能等特性，raid5写入性能比较差，raid6理论上会更差，raid建议如下： 对于性能要求较高的场景，考虑使用raid10的方式来均衡性能和权限，但同时安全性要通过监控+到期更换的方式来弥补 对于安全要求保障较高的场景，建议raid6，其空间在超过4盘时优于raid10 对于空间要求较高的场景，建议raid5

fio测试硬盘io fio使用方法 很多年前我们使用 hdparm 或者 dd 测试磁盘的 io，但是跟随着系统技术和磁盘技术的发展，这些老工具已不再测试准备，或者要增加一些特别的参数，比较麻烦，所以可以选择 fio 来测试硬盘性能 顺序读 fio -filename=/opt/test -iodepth=64 -ioengine=psync -direct=1 -rw=read -bs=4k -size=8g -numjobs=64 -runtime=60 -group_reporting -name=test-read 顺序写 fio -filename=/opt/test -iodepth=64 -ioengine=psync -direct=1 -rw=write -bs=4k -size=8g -numjobs=64 -runtime=60 -group_reporting -name=test-write 随机读 fio -filename=/opt/test -iodepth=64 -ioengine=psync -direct=1 -rw=randread -bs=4k -size=8G -numjobs=64 -runtime=60 -group_reporting -name=test-rand-read 随机写 fio -filename=/opt/test -iodepth=64 -ioengine=psync -direct=1 -rw=randwrite -bs=4k -size=8G -numjobs=64 -runtime=60 -group_reporting -name=test-rand-write 20240415 fio 使用的引擎的话 psync 和 libaio 都是可以的，但是推荐使用 libaio。再就是 io 测试一般指标分为两个，一个是 iops ，一个是 吞吐量 其中 4k 随机读、4k 随机写，适用于 iops 测试 大块如，64k，256k，512k 等适用于吞吐量测试 最后关于参数，numjobs、iodepth，一般这两个参数的大小会最大影响测试结果： 其中 numjobs 是启动的任务，相当于多少个进程进行测试，一般来说不超过cpu核心数即可 iodepth测试io的队列深度，一般来说机械硬盘取1或2，ssd 等可以使用 8 ~ 64 所以最大的 io 队列深度其实是 numjobs x iodepth ， 所以有可能出现如下情况 numjobs 设置为 cpu 核心数、 iodepth 设置 1 or 2，结果不好，iodepth需要设置更大 numjobs 设置为 cpu 核心数， iodepth 设置 1 or 2，测试结果正常，符合iops上限 numjobs 设置为 个位数，iodepth 设置为 32 ~ 64，测试结果正常，符合 iops 上限 以上这些情况都是有可能发生的，所以实际情况下，我们需要根据推荐来进行测试，或者觉得不符合当前磁盘性能的时候进行多次参数的变更测试 以下是针对阿里云 100k iops 的测试: 1. fio --filename=/tmp/test/test.test -size=30G --direct=1 --rw=randread --bs=4k --ioengine=libaio --iodepth=64 --runtime=30s --numjobs=1 --time_based --group_reporting --name=iops-test-job --eta-newline=1 2. fio --filename=/tmp/test/test.test -size=30G --direct=1 --rw=randread --bs=4k --ioengine=libaio --iodepth=64 --runtime=30s --numjobs=4 --time_based --group_reporting --name=iops-test-job --eta-newline=1 3. fio --filename=/tmp/test/test.test -size=30G --direct=1 --rw=randread --bs=4k --ioengine=libaio --iodepth=1 --runtime=30s --numjobs=4 --time_based --group_reporting --name=iops-test-job --eta-newline=1 4. fio --filename=/tmp/test/test.test -size=30G --direct=1 --rw=randread --bs=4k --ioengine=libaio --iodepth=1 --runtime=30s --numjobs=1 --time_based --group_reporting --name=iops-test-job --eta-newline=1 5. fio --filename=/tmp/test/test.test -size=30G --direct=1 --rw=randread --bs=4k --ioengine=libaio --iodepth=1 --runtime=30s --numjobs=32 --time_based --group_reporting --name=iops-test-job --eta-newline=1 6. fio --filename=/tmp/test/test.test -size=30G --direct=1 --rw=randread --bs=4k --ioengine=libaio --iodepth=32 --runtime=30s --numjobs=32 --time_based --group_reporting --name=iops-test-job --eta-newline=1 其中 3、4 测试结果不能达到满速，甚至是非常低，只有几k左右 其他方案 我们也可以选择使用vertica自带的工具测试