서버의 NVMe SSD 스트라이프에서 비정상적으로 낮은 성능을 경험하고 있습니다. 하드웨어는 다음과 같습니다.
- 마더보드: X9DR3-F
- CPU: 듀얼 E5-2650v2
- RAM: 128GB DDR3-1333 UDIMM(16x8GB)
- NVMe 드라이브: 분기 레인이 있는 PCIe 확장기를 통해 4x MZVLB256HBHQ-000L7
lspci -nvv장치에 대한 8GT/s x4 링크를 보여 주며 드라이브가 원하는 대로 PCIe 3.0에서 작동함을 보여줍니다 LnkSta: Speed 8GT/s, Width x4. 이 드라이브의 벤치마크는 약 1.4GB/s 쓰기 작업이 가능한 것으로 나타났습니다.
드라이브에 순차 쓰기를 시도하면 해당 성능의 약 1/3을 얻습니다. 다음은 쓰기 중 619MB/s를 보여주고, 이후 50초 동안 일시 중지되었습니다. 아마도 데이터가 디스크에 완전히 플러시되는 동안일 것입니다.
$ sudo dd if=/dev/zero of=/dev/nvme1n1 bs=16M count=1k status=progress
16726884352 bytes (17 GB, 16 GiB) copied, 27 s, 619 MB/s
1024+0 records in
1024+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 71.8953 s, 239 MB/s
이것이 내 합성 벤치마크와 다른 사람의 합성 벤치마크의 특이한 점이라고 가정하고 4개의 장치를 모두 MD RAID-0에 넣고 다시 시도했습니다.
$ sudo mdadm --create /dev/md0 --level=0 --raid-devices=4 --force --run /dev/nvme?n1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
$ sudo dd if=/dev/zero of=/dev/md0 bs=16M count=2k status=progress
34191966208 bytes (34 GB, 32 GiB) copied, 57 s, 600 MB/s
2048+0 records in
2048+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 79.7502 s, 431 MB/s
더 좋지만 바라는 점이 많습니다. 내 공립 학교 교육 계산을 믿으면 이 드라이브는 초당 430x10에서 600x10메가비트 사이에서 전송되므로 최상의 시나리오는 6gbit입니다. 이상적인 조건에서는 다른 업체의 종합 벤치마크를 기준으로 단순한 all-0 스트라이프 쓰기의 4x 드라이브가 6GByte에 도달할 것으로 예상합니다. 이것이 시스템의 일부 제한 사항이라고 가정하고 관련 없는 40gbps 이더넷 카드를 다른 호스트에 대해 테스트했습니다.
$ iperf -c 10.x.x.x -P 4
------------------------------------------------------------
Client connecting to 10.x.x.x, TCP port 5001
TCP window size: 325 KByte (default)
------------------------------------------------------------
[ 2] local 10.x.x.x port 53750 connected with 10.x.x.x port 5001 (icwnd/mss/irtt=87/8948/196)
[ 1] local 10.x.x.x port 53754 connected with 10.x.x.x port 5001 (icwnd/mss/irtt=87/8948/132)
[ 3] local 10.x.x.x port 53738 connected with 10.x.x.x port 5001 (icwnd/mss/irtt=87/8948/212)
[ 4] local 10.x.x.x port 53756 connected with 10.x.x.x port 5001 (icwnd/mss/irtt=87/8948/107)
[ ID] Interval Transfer Bandwidth
[ 2] 0.0000-10.0027 sec 12.4 GBytes 10.6 Gbits/sec
[ 1] 0.0000-10.0180 sec 12.7 GBytes 10.9 Gbits/sec
[ 3] 0.0000-10.0179 sec 10.6 GBytes 9.05 Gbits/sec
[ 4] 0.0000-10.0180 sec 10.5 GBytes 8.97 Gbits/sec
[SUM] 0.0000-10.0011 sec 46.1 GBytes 39.6 Gbits/sec
이 네트워크 카드는 SSD 성능과 아무 관련이 없지만 시스템이 PCIe를 통해 최소 40gbit 링크를 포화시킬 수 있다는 것을 보여줍니다. 특히 해당 카드가 4x4가 아닌 x8 링크이기 때문입니다. 한 가지 주목할 만한 점은 이더넷 카드는 CPU1_SLOT1에 있고 SSD는 CPU2_SLOT4에 있다는 것입니다. 하지만 SLOT4는 CPU2에 직접 매달려 있고 SLOT1은 CPU1에 직접 매달려 있기 때문에 이것이 성능의 엄청난 차이를 설명할 수 있는지 확실하지 않습니다. CPU 사이에는 듀얼 8GT/s QPI 링크가 있으며 추가 스위치는 없습니다.
나에게는 읽기 성능도 그에 따라 낮다는 점은 주목할 가치가 있습니다. 여기에는 파일 시스템 오버헤드가 없으며 이는 단지 원시 플래시 및 PCIe 성능에 영향을 미칩니다. 이는 더 적은 하드웨어의 RAID-5에서 4x 소비자 SATA HDD의 읽기 성능에 관한 것이므로 절대 용납할 수 없을 정도로 느립니다.
$ sudo dd if=/dev/md0 of=/dev/null bs=16M count=8k
8192+0 records in
8192+0 records out
137438953472 bytes (137 GB, 128 GiB) copied, 214.738 s, 640 MB/s
top이 읽기 작업 중 검사 결과 ddCPU가 100% 소모되었으며, 그 중 97%가 시스템 대기에 사용된 것으로 나타났습니다. 나머지 31개 스레드는 어느 정도 유휴 상태였습니다. 여기에서 발생한 성능 문제 진단은 어디서 시작할 수 있나요?
이것이 단지 DD의 문제라고 가정하고 fio로 다시 시도했습니다. MD 장치를 유지하고 기본 설정을 선택할 수 있도록 XFS로 포맷한 후 마운트하고 다음에 설명된 테스트를 실행했습니다.https://cloud.google.com/compute/docs/disks/benchmarking-pd-performance:
순차적 쓰기
Run status group 0 (all jobs):
WRITE: bw=1348MiB/s (1414MB/s), 1348MiB/s-1348MiB/s (1414MB/s-1414MB/s), io=80.8GiB (86.7GB), run=61368-61368msec
Disk stats (read/write):
md0: ios=0/710145, merge=0/0, ticks=0/397607236, in_queue=397607236, util=99.82%, aggrios=0/177558, aggrmerge=0/2, aggrticks=0/99452549, aggrin_queue=99465067, aggrutil=99.62%
nvme0n1: ios=0/177568, merge=0/5, ticks=0/56627328, in_queue=56635784, util=97.96%
nvme3n1: ios=0/177536, merge=0/1, ticks=0/145315089, in_queue=145331709, util=99.62%
nvme2n1: ios=0/177559, merge=0/3, ticks=0/151148103, in_queue=151165889, util=99.44%
nvme1n1: ios=0/177569, merge=0/0, ticks=0/44719677, in_queue=44726889, util=97.87%
무작위 쓰기
Run status group 0 (all jobs):
WRITE: bw=101MiB/s (106MB/s), 101MiB/s-101MiB/s (106MB/s-106MB/s), io=6074MiB (6370MB), run=60003-60003msec
Disk stats (read/write):
md0: ios=0/1604751, merge=0/0, ticks=0/623304, in_queue=623304, util=100.00%, aggrios=0/401191, aggrmerge=0/2, aggrticks=0/153667, aggrin_queue=153687, aggrutil=99.99%
nvme0n1: ios=0/402231, merge=0/3, ticks=0/156754, in_queue=156775, util=99.98%
nvme3n1: ios=0/401144, merge=0/2, ticks=0/149648, in_queue=149667, util=99.98%
nvme2n1: ios=0/400158, merge=0/0, ticks=0/150380, in_queue=150400, util=99.98%
nvme1n1: ios=0/401233, merge=0/4, ticks=0/157887, in_queue=157908, util=99.99%
순차적 읽기
Run status group 0 (all jobs):
READ: bw=6244MiB/s (6547MB/s), 6244MiB/s-6244MiB/s (6547MB/s-6547MB/s), io=367GiB (394GB), run=60234-60234msec
Disk stats (read/write):
md0: ios=3089473/14, merge=0/0, ticks=272954324/220, in_queue=272954544, util=99.98%, aggrios=779529/3, aggrmerge=6/1, aggrticks=68744470/104, aggrin_queue=68744621, aggrutil=99.60%
nvme0n1: ios=779520/6, merge=12/2, ticks=24023533/1, in_queue=24023534, util=98.84%
nvme3n1: ios=779519/2, merge=14/0, ticks=145571896/378, in_queue=145572449, util=99.60%
nvme2n1: ios=779536/3, merge=0/1, ticks=77038488/3, in_queue=77038492, util=98.90%
nvme1n1: ios=779544/3, merge=0/1, ticks=28343963/34, in_queue=28344012, util=98.81%
무작위 읽기
Run status group 0 (all jobs):
READ: bw=372MiB/s (390MB/s), 372MiB/s-372MiB/s (390MB/s-390MB/s), io=21.8GiB (23.4GB), run=60002-60002msec
Disk stats (read/write):
md0: ios=5902401/10, merge=0/0, ticks=2684388/0, in_queue=2684388, util=100.00%, aggrios=1475009/3, aggrmerge=608/0, aggrticks=685706/0, aggrin_queue=685706, aggrutil=99.90%
nvme0n1: ios=1475288/4, merge=632/1, ticks=697246/0, in_queue=697246, util=99.89%
nvme3n1: ios=1475328/2, merge=611/0, ticks=678849/1, in_queue=678850, util=99.89%
nvme2n1: ios=1474625/3, merge=588/1, ticks=673908/0, in_queue=673909, util=99.90%
nvme1n1: ios=1474795/3, merge=602/0, ticks=692822/1, in_queue=692822, util=99.90%
이는 훨씬 더 빠르며 어레이에서 여러 스레드를 사용하는 것이 이점이 있음을 보여 주지만 온라인의 다른 벤치마크에서는 이 드라이브가 개별적으로 1GB/s 쓰기를 수행하는 것으로 나타났습니다(반면 저는 4개 모두 결합하여 최고 1.4GB/s에 도달했습니다). UserBenchmark 결과는 드라이브당 2.2GB/s의 읽기 속도를 보았으므로 6GB/s의 읽기 속도가 상황에 따라 꽤 잘 수행되고 있습니다.
그렇다면 단일 프로세스 성능을 향상시키기 위해 수행할 작업이 있습니까?
답변1
Samsung MZVLB256HBHQ-000L7은 소형 SSD(256GB)이므로 여러 GB에 걸쳐 쓰기하는 경우 내부 NAND 대역폭 병목 현상이 발생합니다. 당신은 그들을 다듬을 수 있습니다 (현재 드라이브에 저장된 모든 데이터 손실) 내부 pSLC 캐시를 정리하여 첫 번째 벤치마크에서 더 많은 대역폭을 사용하지만 빠르게 다시 포화 상태가 됩니다.
답변2
삼성 MZVL* 드라이브에 대한 나의 경험은 형편없었습니다. 보다https://superuser.com/questions/1721288/ssd-performance-falls-off-a-cliff
귀하의 드라이브에서 평판이 좋은 사양을 찾으려고 노력하고 있지만 제 추측으로는 드라이브에 DRAM이 없다는 것입니다.
답변3
글쎄요, 하기 싫지만 궁극적으로는 답변을 하고 질문을 마무리해야겠습니다. PM981 드라이브하다512MB DRAM 캐시가 있고 12GB SLC 캐시도 제공하므로 속도가 빨라야 합니다. RAID-0에 있는 4개는 비명을지를 것입니다.
https://www.techpowerup.com/ssd-specs/samsung-pm981a-256-gb.d784
이 문제를 해결하지 못했기 때문에 대신 NAS를 구입했습니다.