☰

Linux 上的 SSD 随机读取性能较差

tag-icon • tag-icon performance ssd
Linux 上的 SSD 随机读取性能较差

我最近得到了一个Intel 320系列SSD，并且我很难实现随机 4K 读取所宣传的 38K IOPS。

两者都带有fio和我自己的 hacked-together 程序，我看到大约 6K IOPS。这几乎就像 IO 深度大小并不重要，内核试图一次获取一个块。

例子：

$ cat job
[randread]
filename=/dev/sdb2
rw=randread
size=128m
blocksize=4k
ioengine=libaio
iodepth=64
direct=1

$ sudo fio job
randread: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [25423K/0K /s] [6207/0 iops] [eta 00m:00s]
randread: (groupid=0, jobs=1): err= 0: pid=4678
  read : io=131072KB, bw=24852KB/s, iops=6213, runt=  5274msec
    slat (usec): min=1, max=94, avg= 5.00, stdev= 2.88
    clat (usec): min=312, max=13070, avg=10290.25, stdev=1399.78
    bw (KB/s) : min=23192, max=24464, per=97.08%, avg=24125.60, stdev=383.70
  cpu          : usr=15.74%, sys=22.57%, ctx=31642, majf=0, minf=88
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=99.8%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued r/w: total=32768/0, short=0/0
     lat (usec): 500=0.01%, 750=0.01%, 1000=0.03%
     lat (msec): 2=0.05%, 4=0.10%, 10=20.10%, 20=79.70%

Run status group 0 (all jobs):
   READ: io=131072KB, aggrb=24852KB/s, minb=25448KB/s, maxb=25448KB/s, mint=5274msec, maxt=5274msec

Disk stats (read/write):
  sdb: ios=30453/0, merge=850/0, ticks=319060/0, in_queue=319060, util=98.09%

该系统是Linux 2.6.35-31-generic #63-Ubuntu SMP Mon Nov 28 19:29:10 UTC 2011 x86_64 GNU/Linux./dev/sdb2上面是 80GB SSD 上的约 10GB 分区。fio是1.38版本。

非常感谢对可能出现问题的想法。

PS：上述测试( )中的分区/dev/sdb2是在4K边界上对齐的。从较大的跨度（大小=10g）读取没有帮助。

答案1

参见讨论我可以将 Linux 系统配置为更积极的文件系统缓存吗？

简而言之，您可能需要调整一些设备队列设置。我猜测内核错误地猜测了调度程序或队列设置或手动设置。

尝试

grep . /sys/block/sd*/{queue/{nr_requests,nomerges,rotational,scheduler},device/queue_depth}

和

lsblk

来调试问题。如果您可以容忍 NCQ 引起的单次读取延迟，则应至少queue_depth设置为 31，该值应为零，对于 SSD 也应为零。选择正确的会比较困难，但对于原始 IOPS 来说应该足够好了。我发现nr_requestsnomergesrotationalschedulernoop正确调整 cfq更好地处理现实世界的要求。

并确保磁盘以 SATA + AHCI 连接并且启用了 NCQ。否则，从磁盘中取出所有内容的希望很小。

答案2

你的分区是正确对齐？如果您不是在 4k 边界上开始分区，则所有 4k 读取都不会排队，从而产生边界交叉，最坏的情况是使 I/O 增加一倍。

相关内容