Mauvaises performances IO - PCIe NVMe Samsung 950 pro
Je viens de terminer une construction matérielle en espérant que le nouveau lecteur NVMe apportera un gain considérable. Mes performances antérieures étaient inférieures aux attentes (environ 3 Go transférés). J'ai donc remplacé la carte mère/cpu/memory/hdd. Alors que la performance est le double de ce qu'elle était , elle reste toujours la moitié de ce que j'ai à mes 3 ans MacBook Pro avec un lecteur SATA6.
- CPU: i7-5820k 6core
- Mobo: MSI X99A MPOWER
- Mémoire: 32 Go
- Lecteur: Samsung 950 pro NVMe PCIe
Ubuntu (également confirmé avec 16.04.1 LTS):
Release: 15.10
Codename: wily
4.2.0-16-generic
$ Sudo blkid
[Sudo] password for kross:
/dev/nvme0n1p4: UUID="2997749f-1895-4581-abd3-6ccac79d4575" TYPE="swap"
/dev/nvme0n1p1: LABEL="SYSTEM" UUID="C221-7CA5" TYPE="vfat"
/dev/nvme0n1p3: UUID="c7dc0813-3d18-421c-9c91-25ce21892b9d" TYPE="ext4"
Voici mes résultats de test:
sysbench --test=fileio --file-total-size=128G prepare
sysbench --test=fileio --file-total-size=128G --file-test-mode=rndrw --max-time=300 --max-requests=0 run
sysbench --test=fileio --file-total-size=128G cleanup
Operations performed: 228000 Read, 152000 Write, 486274 Other = 866274 Total
Read 3.479Gb Written 2.3193Gb Total transferred 5.7983Gb (19.791Mb/sec)
1266.65 Requests/sec executed
Test execution summary:
total time: 300.0037s
total number of events: 380000
total time taken by event execution: 23.6549
per-request statistics:
min: 0.01ms
avg: 0.06ms
max: 4.29ms
approx. 95 percentile: 0.13ms
Threads fairness:
events (avg/stddev): 380000.0000/0.00
execution time (avg/stddev): 23.6549/0.00
Le planificateur est défini sur nonename__:
# cat /sys/block/nvme0n1/queue/scheduler
none
Voici les informations lspciname__:
# lspci -vv -s 02:00.0
02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd Device a802 (rev 01) (prog-if 02 [NVM Express])
Subsystem: Samsung Electronics Co Ltd Device a801
Physical Slot: 2-1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 45
Region 0: Memory at fb610000 (64-bit, non-prefetchable) [size=16K]
Region 2: I/O ports at e000 [size=256]
Expansion ROM at fb600000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L1, Exit Latency L0s <4us, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR+, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+
EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable+ Count=9 Masked-
Vector table: BAR=0 offset=00003000
PBA: BAR=0 offset=00002000
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [148 v1] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [158 v1] Power Budgeting <?>
Capabilities: [168 v1] #19
Capabilities: [188 v1] Latency Tolerance Reporting
Max snoop latency: 0ns
Max no snoop latency: 0ns
Capabilities: [190 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=10us PortTPowerOnTime=10us
Kernel driver in use: nvme
hdparmname__:
$ Sudo hdparm -tT --direct /dev/nvme0n1
/dev/nvme0n1:
Timing O_DIRECT cached reads: 2328 MB in 2.00 seconds = 1163.98 MB/sec
Timing O_DIRECT disk reads: 5250 MB in 3.00 seconds = 1749.28 MB/sec
hdparm -v:
Sudo hdparm -v /dev/nvme0n1
/dev/nvme0n1:
SG_IO: questionable sense data, results may be incorrect
multcount = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 488386/64/32, sectors = 1000215216, start = 0
fstab
UUID=453cf71b-38ca-49a7-90ba-1aaa858f4806 / ext4 noatime,nodiratime,errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
#UUID=C221-7CA5 /boot/efi vfat defaults 0 1
# swap was on /dev/sda4 during installation
UUID=8f716653-e696-44b1-8510-28a1c53f0e8d none swap sw 0 0
UUID=C221-7CA5 /boot/efi vfat defaults 0 1
fio
Cela a quelques points de repère comparables c'est loin. Lorsque j'ai testé avec fio et désactivé syncname__, l'histoire est différente:
sync=1
1 job - write: io=145712KB, bw=2428.5KB/s, iops=607, runt= 60002msec
7 jobs - write: io=245888KB, bw=4097.9KB/s, iops=1024, runt= 60005msec
sync=0
1 job - write: io=8157.9MB, bw=139225KB/s, iops=34806, runt= 60001msec
7 jobs - write: io=32668MB, bw=557496KB/s, iops=139373, runt= 60004msec
Voici les résultats complets de syncpour un travail et 7 emplois:
$ Sudo fio --filename=/dev/nvme0n1 --direct=1 --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=1 --runtime=60 --time_based --group_reporting --name=journal-test
journal-test: (g=0): rw=write, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1
fio-2.1.11
Starting 1 process
Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/2368KB/0KB /s] [0/592/0 iops] [eta 00m:00s]
journal-test: (groupid=0, jobs=1): err= 0: pid=18009: Wed Nov 18 18:14:03 2015
write: io=145712KB, bw=2428.5KB/s, iops=607, runt= 60002msec
clat (usec): min=1442, max=12836, avg=1643.09, stdev=546.22
lat (usec): min=1442, max=12836, avg=1643.67, stdev=546.23
clat percentiles (usec):
| 1.00th=[ 1480], 5.00th=[ 1496], 10.00th=[ 1512], 20.00th=[ 1528],
| 30.00th=[ 1576], 40.00th=[ 1592], 50.00th=[ 1608], 60.00th=[ 1608],
| 70.00th=[ 1608], 80.00th=[ 1624], 90.00th=[ 1640], 95.00th=[ 1672],
| 99.00th=[ 2192], 99.50th=[ 6944], 99.90th=[ 7328], 99.95th=[ 7328],
| 99.99th=[ 7520]
bw (KB /s): min= 2272, max= 2528, per=100.00%, avg=2430.76, stdev=61.45
lat (msec) : 2=98.44%, 4=0.58%, 10=0.98%, 20=0.01%
cpu : usr=0.39%, sys=3.11%, ctx=109285, majf=0, minf=8
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
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.0%, >=64=0.0%
issued : total=r=0/w=36428/d=0, short=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: io=145712KB, aggrb=2428KB/s, minb=2428KB/s, maxb=2428KB/s, mint=60002msec, maxt=60002msec
Disk stats (read/write):
nvme0n1: ios=69/72775, merge=0/0, ticks=0/57772, in_queue=57744, util=96.25%
$ Sudo fio --filename=/dev/nvme0n1 --direct=1 --sync=1 --rw=write --bs=4k --numjobs=7 --iodepth=1 --runtime=60 --time_based --group_reporting --name=journal-test
journal-test: (g=0): rw=write, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1
...
fio-2.1.11
Starting 7 processes
Jobs: 6 (f=6): [W(2),_(1),W(4)] [50.4% done] [0KB/4164KB/0KB /s] [0/1041/0 iops] [eta 01m:00s]
journal-test: (groupid=0, jobs=7): err= 0: pid=18025: Wed Nov 18 18:15:10 2015
write: io=245888KB, bw=4097.9KB/s, iops=1024, runt= 60005msec
clat (usec): min=0, max=107499, avg=6828.48, stdev=3056.21
lat (usec): min=0, max=107499, avg=6829.10, stdev=3056.16
clat percentiles (usec):
| 1.00th=[ 0], 5.00th=[ 2992], 10.00th=[ 4512], 20.00th=[ 4704],
| 30.00th=[ 5088], 40.00th=[ 6176], 50.00th=[ 6304], 60.00th=[ 7520],
| 70.00th=[ 7776], 80.00th=[ 9024], 90.00th=[10048], 95.00th=[12480],
| 99.00th=[15936], 99.50th=[18048], 99.90th=[22400], 99.95th=[23936],
| 99.99th=[27008]
bw (KB /s): min= 495, max= 675, per=14.29%, avg=585.60, stdev=28.07
lat (usec) : 2=4.41%
lat (msec) : 2=0.57%, 4=4.54%, 10=80.32%, 20=9.92%, 50=0.24%
lat (msec) : 250=0.01%
cpu : usr=0.14%, sys=0.72%, ctx=173735, majf=0, minf=63
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
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.0%, >=64=0.0%
issued : total=r=0/w=61472/d=0, short=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: io=245888KB, aggrb=4097KB/s, minb=4097KB/s, maxb=4097KB/s, mint=60005msec, maxt=60005msec
Disk stats (read/write):
nvme0n1: ios=21/122801, merge=0/0, ticks=0/414660, in_queue=414736, util=99.90%
Alignement
J'ai vérifié l'alignement avec partedname__, ainsi que les calculs basés sur http://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/ssd- partition-alignement-tech-brief.pdf
kross@camacho:~$ Sudo parted
GNU Parted 3.2
Using /dev/nvme0n1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) print all
Model: Unknown (unknown)
Disk /dev/nvme0n1: 1000215216s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 2048s 206847s 204800s fat32 EFI system partition boot, esp
2 206848s 486957055s 486750208s ntfs msftdata
3 486957056s 487878655s 921600s ntfs hidden, diag
4 590608384s 966787071s 376178688s ext4
5 966787072s 1000214527s 33427456s linux-swap(v1)
kross@camacho:~$ Sudo parted /dev/nvme0n1
GNU Parted 3.2
Using /dev/nvme0n1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) align-check opt 1
1 aligned
(parted) align-check opt 2
2 aligned
(parted) align-check opt 3
3 aligned
(parted) align-check opt 4
4 aligned
(parted) align-check opt 5
5 aligned
TLDR;
J'ai le sentiment d'avoir quelque chose de fondamentalement mal réglé, bien que mes recherches n'aient rien révélé. Je m'attends à un débit d'environ 4 fois mon vieux Macbook Pro 3 ans avec SATA6, et j'en reçois la moitié avec NVMe. J'ai ajouté noatime,nodiratime qui m'a apporté une très légère amélioration, mais rien à voir avec le 4x que j'attendais. J'ai re-partitionné/réinstallé un nouveau serveur 15.10 juste pour m'assurer que rien ne m'attendait et que je obtenais les mêmes résultats.
Mes résultats fioau-dessus de sync/no sync sont-ils indicatifs d'un problème?
J'ai donc une table rase et je peux tout essayer. Que puis-je essayer d’améliorer mes performances? Toutes les références sont les bienvenues.
Attention: Cette réponse est ancienne. Depuis Linux 4.19, blk_mq est le planificateur par défaut . Il est fort probable que le problème de votre système SSD PCIe NVMe dont les tiges sont lentes se présente ailleurs.
Réponse originale:
S'il-vous-plait ajoutez
scsi_mod.use_blk_mq=1
paramètres de démarrage de votre noyau, sinon je ne pense pas que vous constaterez les avantages de la file d’attente de commande accrue de NVMe et de commande par file d’attente.
Note: Je sais que c'est pour Arch, mais vous pouvez aussi jeter un coup d'œil au Wiki pour plus d'informations sur le réglage des E/S.
Merci pour votre question, cela a été incroyablement utile pour moi.
J'ai une expérience très similaire, une configuration matérielle différente (j'utilise un SSD Intel NVMe). Mais je suis aussi sous Ubuntu 16.04. Compte tenu de votre preuve et d'un résultat similaire trouvé dans cet article , j'étais convaincu que le problème était lié à la manière dont Ubuntu configurait les disques NVMe.
J'étais déterminé à résoudre le problème sans abandonner complètement Ubuntu. Mais peu importe ce que je faisais, je ne pouvais pas obtenir des vitesses supérieures à 2 000 Mo/s lorsque je testais avec hdparm exactement comme vous l'avez décrit.
J'ai donc creusé un peu et trouvé un guide fourni par Intel. J'ai essayé tout ce qu'ils ont suggéré dans ce guide et j'ai trouvé qu'une partie était différente. En bas, il est question d’aligner correctement les partitions du lecteur. C'est la partie qui ne correspond pas à mon installation. Mon bloc de départ n'était pas divisible par 4096 octets. Il utilisait une taille de secteur de 512 octets au lieu d'une taille de secteur de 4 ko.
Effectivement, j'ai formaté le disque pour démarrer la partition à une valeur divisible par 4096 et FINALEMENT, j'ai été capable de casser des vitesses de 2000 Mo/s.
À l'heure actuelle, il est en moyenne de 2,3 Go/s, alors que je pense qu'il sera un peu plus élevé. Je le blâme sur le fait que, lorsque j’exécute Sudo fdisk -l, le lecteur NVMe est toujours affiché avec une taille de secteur physique de 512 octets. Je prévois de continuer à enquêter mais j'espère que cela vous aidera!
Ce fil a un an (octobre 2016). L'une des réponses les plus votées recommande un pilote Intel NVMe âgé de deux ans (2015).
En février 2017, bien que Samsung ait publié un Firmware Update qui utilise un programme d’installation ISO de démarrage basé sur Linux. Sur le même lien, vous pouvez installer des pilotes pour Windows 7/8/10. J'installerai les deux bientôt sur mon nouveau Samsung 960 Pro et le tout nouvel ordinateur portable Dell basé sur i7-6700. Parallèlement au BIOS clignotant et à la mise à jour d'autres pilotes basés sur Dell.
Je pense qu'il est important de revenir sur ces anciennes discussions et de fournir aux nouveaux utilisateurs des liens actuels (à compter du 11 octobre 2017) afin qu'ils aient toutes les options ouvertes.
De nombreuses recherches Google ont été renvoyées concernant les performances lentes du Samsung 960 Pro sous Linux, soit une vitesse deux fois moins rapide que Windows. J'encourage donc tout le monde à rechercher autant d'options que possible.
Après avoir implémenté le paramètre de noyau scsi_mod.use_blk_mq=1:
$ systemd-analyze
Startup finished in 7.052s (firmware) + 6.644s (loader) + 2.427s (kernel) + 8.440s (userspace) = 24.565s
Suppression du paramètre du noyau et redémarrage:
$ systemd-analyze
Startup finished in 7.060s (firmware) + 6.045s (loader) + 2.712s (kernel) + 8.168s (userspace) = 23.986s
Donc, il semblerait maintenant que scsi_mod.use_blk_mq=1 rend le système plus lent pas plus rapide. À un moment donné, cela aurait peut-être été bénéfique.
Voici quelques informations intéressantes: sous Windows, le lecteur ne fonctionne pas selon les critères d'évaluation jusqu'à ce que le vidage de la mémoire cache soit désactivé. Généralement, cela ne se fait pas directement; à la place, le pilote du fournisseur (dans ce cas, le pilote Samsung NVMe) est installé.
Si vous comparez avec le pilote du fournisseur, puis désactivez le vidage de la mémoire cache dans Windows, vous obtenez les mêmes numéros. Ce serait peu probable si le fournisseur n'ignorait pas le vidage du cache.
Traduit en Linux-land, cela signifie que sous Windows, pour obtenir les grands chiffres de référence que vous voyez dans toutes les revues, vous devez désactiver fsync, avec tout ce que cela signifie pour la fiabilité (pas de fsync, ni plus précisément, aucune barrière en écriture). une perte de puissance au mauvais moment peut endommager l’ensemble du système de fichiers, selon l’implémentation (les écritures réorganisées créent des situations "impossibles").
Les disques SSD "centre de données" de Samsung sont livrés avec des condensateurs pour garantir le vidage correct des données en cache. Ce n'est pas le cas avec leurs lecteurs grand public.
Je viens juste de résoudre ce problème à partir des principes de base, après avoir ajouté un NVMe de 1 To à ma nouvelle version hier. Je ne suis pas particulièrement heureux et j'ai pris contact avec le support technique Samsung pour voir ce qu'il en dit - mais je doute que je l'entende.
La plupart des SSD tombent à plat si sync = 1 (D_SYNC) est un drapeau. Malheureusement, il s’agit d’un problème bien connu des revues Ceph. Consultez cette page pour plus d'informations et une liste des lecteurs qui fonctionnent correctement avec la synchronisation activée:
Je ne peux pas encore commenter, je dois donc répondre. :-(
Je n'ai pas de lecteur comparable, mais je suppose que les valeurs de hdparm sont bonnes. Si tel est le cas, je suppose que vous utilisez simplement sysbench de manière sous-optimale. Essayez d’expérimenter avec le paramètre --num-threads pour générer plus de charge sur le lecteur. Au moins sur mon ordinateur, la différence entre 1 thread (par défaut) et 16 threads était d'environ 1: 4 sur un SSD SATA standard. D'après ce que je comprends, les disques NVMe commencent à briller, plus les tâches parallèles les sollicitent.
Mon emplacement M.2 était plafonné à 10Mbps. J'ai utilisé une carte PCIe pour contourner cette limitation: https://www.Amazon.com/Lycom-DT-120-M-2-PCIe-to-PCIe-3-0-x4-Adapter-Support -M-2-PCIe-2280-2260-2242/dp/B00MYCQP38 /
Votre carte mère indique que le débit total est de 32 Mbit/s et que c'est peut-être vrai, mais je pensais que je mentionnerais l'adaptateur car il fonctionnait pour moi (je me suis doublez la vitesse de connexion dans le slot M.2 intégré). Je pense que c'était 25 $ et si vous avez déjà passé suffisamment de temps à jouer du violon, cela pourrait valoir le coup d'essayer.
J'ai écrit à propos de mon expérience dans mon compte rendu sur Amazon: https://www.Amazon.com/gp/customer-reviews/R21BXILGXW4D9C/ref=cm_cr_arp_d_rvw_ttl?ie=UTF8&.IN=B01639694M