第一部分测试脚本

fio -name=1io -filename=io.speedtest -runtime=30 -direct=1 -bs=8k -rw=randrw  -rwmixread=70  -size=4G  
-thread  -group_reporting  -numjobs=1  --iodepth=1 -ioengine=sync/libaio   >randread8k_70_1.txt 

注意这边的变量主要有: 
到不同的分区挂载目录进行测试主要不通设备
1. 一块1.92T镁光企业级SSD 单盘直连SATA.  -飞腾S2500 64C *2 1T内存
2. 3块1.92T镁光企业级SSD 三盘PM8204-2G RAID5. -海光7285 2.1Ghz 32c *2 1T内存
3. 6块 4T希捷 near-line SATA HDD 7.2KRPM 机械硬盘 RAID10 PM8204-2G -飞腾S2500 64C *2 1T内存
4  6块 4T希捷 near-line SATA HDD 7.2KRPM 机械硬盘 RAID10 PM8204-2G -海光7285 2.1Ghz 32c *2 1T内存
5 为了快速出结果,本次只进行30s的测试验证.

注意我这边选用了不同的参数
1. sync/libaio 发现在direct-1的情况下差异比较小, 所以我这边都选择了 sync 的ioengine的方式进行处理.
2. numjobs 我这边使用了1 到60的不同数字进行验证,基本上获取最大值,然后只比较最大值. 
3. iodepth 我猜测只有nvme的基于PCI-E 直连CPU的才支撑较大的IO-depth 我这边发现不管是SATAD的SSD还是HDD 对IO-depth的增加提升都很有限. 
4. 使用线程模式而不是进程模式. 
5. 多jobs 使用 group-reporting模式进行汇总结果并且转储. 避免分析起来很复杂. 
6. 使用混写读写模式(模拟数据库) 70%的读,30%的写入.

Raid卡的配置

1. maxcache全开
2. 磁盘缓存全开.
3. raid卡的缓存设置为70%读 30%写入.
4. 条带大小设置为默认值256KB

结果分析部分

• 注意我这边分析的是最优秀的测试结果数据,但是并不一定是IO的极限值

• 举例: HDD飞腾上面32线程的读是18.2M,但是64线程是18.4M. 但是32线程的使用率和延迟比64线程好非常多

• 注意本次只关注95%的时间: 比如飞腾HDD32线程是 56886, 64线程是 123208 差了一倍多.

• 本次只列出具体结果. 主要是分析8KB的读写以及95%的延迟的时间

• 注意 因为都是测试的8KB, 本次不写IOPS, 直接写带宽, IOPS最简单的MB数字乘以125就出来了.

分析结果部分

• 注意带宽单位是MB

• 注意延迟时间是95%的时间

• 飞腾的HDD的写入测试结果不太正常. 我记得raid卡的设置都是一样的. 等上架了再次验证.

• 增加jobs和queue可以增加IO,但是会导致latency增加到无法接受的成都.

• 注意我这边使用命令进行简要分析
  for i in
  ls; do echo $i ; tail -n 5 $i ; done
  

部分结果为:

• 带宽为 MiB/S

• 延迟时间的单位为 微秒