☰

Linux에서 SSD 무작위 읽기 성능이 좋지 않습니다.

tag-icon • tag-icon performance ssd
Linux에서 SSD 무작위 읽기 성능이 좋지 않습니다.

최근에 하나 받았어요인텔 320 시리즈 SSD, 임의 4K 읽기에 대해 광고된 38K IOPS를 달성하는 데 어려움을 겪었습니다.

둘 다 같이 오는데fio내 자체 해킹 프로그램을 사용하면 약 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/Linux80GB /dev/sdb2SSD의 ~10GB 파티션입니다. fio1.38 버전입니다.

무엇이 잘못될 수 있는지에 대한 어떤 아이디어라도 크게 감사하겠습니다.

PS: 위 테스트( )의 파티션은 /dev/sdb24K 경계에 정렬되어 있습니다. 더 큰 범위(크기=10g)에서 읽는 것은 도움이 되지 않습니다.

답변1

토론 보기파일 시스템 캐싱에 있어 Linux 시스템을 보다 적극적으로 구성할 수 있습니까?

즉, 일부 장치 대기열 설정을 조정해야 할 수도 있습니다. 커널이 스케줄러나 대기열 설정을 잘못 추측하거나 수동으로 설정하고 있는 것 같습니다.

노력하다

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

그리고

lsblk

문제를 디버깅합니다. NCQ로 인해 발생하는 단일 읽기 대기 시간을 허용할 수 있는 경우 queue_depth이를 31 이상으로 설정해야 하며 이는 0이어야 하며 SSD의 경우 0이어야 합니다. 올바른 것을 선택하는 것은 어렵지만 원시 IOPS에는 충분할 것입니다. 내가 찾은nr_requestsnomergesrotationalschedulernoop올바른 조정 cfq실제 요구 사항을 더 잘 처리합니다.

그리고 디스크가 SATA + AHCI로 연결되어 있고 NCQ가 활성화되어 있는지 확인하세요. 그렇지 않으면 디스크에서 모든 것을 꺼낼 수 있는 가능성이 거의 없습니다.

답변2

귀하의 파티션은올바른 정렬? 4k 경계에서 분할을 시작하지 않으면 모든 4k 읽기가 대기열에 추가되지 않아 경계 교차가 발생하고 최악의 경우 I/O가 두 배가 됩니다.

관련 정보