2 votes

Les SSD NVMe sont beaucoup moins performants sous ubuntu 20.04.2 que sous Windows.

Sous Windows, en utilisant AS-SSD, j'ai trouvé que mon Kingston A2000 donnait 2000 MB/s en lecture et 1700 MB/s en écriture. Sur ubuntu 20.04.2, en utilisant le benchmark GNOME-DiskUtility, il donne 2100 MB/s en lecture, mais 430 MB/s en écriture.

Qu'est-ce que je rate ? Ceci est fait en fait dans un hôte Proxmox, dans les deux OS invités, avec le même SSD qui leur est passé dans chaque test.

2voto

rsr911 Points 234

Si vous voulez vraiment tester un disque NVMe, vous avez besoin d'un fichier d'un millième de la taille du disque pour vider le cache du disque, sinon vous ne faites que comparer les vitesses du cache. Ainsi, sur un disque de 1 To, la taille de votre fichier de test doit être de 1 Go. Ajustez en fonction de la taille de votre disque. Quel programme utilisez-vous pour effectuer des tests sous Windows ?

J'ai une paire de disques Samsung 980 Pro PCIe 4.0 de 500 Go en Linux raid 0, avec un fichier de 1 Go (1/1000e de la taille de la partition), j'obtiens 13,0 Go/s, exactement là où je m'y attendais. J'obtiens environ 1,3 Go/s en écriture, ce qui est bien inférieur à ce que l'on obtient avec un benchmark Windows comme Crystal Disk Mark. Je ne suis pas certain de la raison de cette différence. Cependant, j'ai fait quelques tests en situation réelle en lisant sur un disque PCIe 3.0 de 1 To et en écrivant sur mon raid, de gros fichiers de plus de 35 Go et mon raid écrit à la pleine vitesse de lecture du disque PCIe 3.0, ce qui indique que le Disk Bench d'Ubuntu est éteint et que les performances en situation réelle sont très bonnes.

Voici donc ce que nous savons : Deux systèmes complètement différents obtiennent un rapport lecture/écriture similaire en utilisant Gnome-Disk-Utility, mais mes tests indépendants indiquent que le test Ubuntu est en quelque sorte "défectueux" ou qu'il rapporte une autre sorte de test pour les écritures, comme peut-être des écritures aléatoires.

Une chose que vous pouvez faire pour un test dans le monde réel, si vous avez un deuxième NVMe pour lire et écrire est :

fallocate -l 100G test.img

Cela crée très rapidement un faux fichier de 100 Go (107,4 Gb) rempli de zéros, puis le déplace d'avant en arrière avec un chronomètre. J'obtiens entre 1,8 Go/s et 2,3 Go/s selon le sens dans lequel je vais. J'ai une autre paire de disques 4.0 en route avec l'intention de mettre mon système d'exploitation sur une matrice NVMe Raid 5 Linux et quand je les recevrai, ainsi que la carte 4.0 que j'attends également, je prévois de les configurer initialement comme une paire en Raid 0 et d'effectuer ce test de va-et-vient ainsi que de chronométrer des fichiers réels, comme des images de disque. Pour moi, le benchmarking est intéressant, mais je veux connaître les performances réelles.

J'ai oublié d'ajouter à mon commentaire. Les disques NVMe ont une flash NAND assez rapide mais leur vitesse réelle provient du cache rapide du disque, certains tests donnent une fausse impression de vitesse en ne remplissant que le cache alors qu'un test comme le disk bench que vous avez fait dans Ubuntu écrit 100 fichiers de 10MB par défaut ou 1GB au total. Sur mes disques Samsung, la SDRAM DDR4 est de 1 GB par 1TB de taille de disque, donc 512MB sur mes disques de 500GB. Partitionnés en Raid 1, j'ai 1 Go de cache au total. Le premier fichier (1 Go) le remplit, les 99 suivants mesurent la vitesse réelle de la NAND. 100 Go en moins d'une minute, c'est impressionnant, quelle que soit la manière dont on le découpe. Lors d'un test de lecture, il s'agit simplement de lire ce fichier de 1 Go directement depuis le cache (à mon avis), alors que lors d'un test d'écriture, le fichier doit être placé sur le disque et vous voyez donc la vitesse d'écriture réelle du disque. C'est pour cette raison que les lecteurs NVMe, bien que très rapides, ne sont pas vraiment ce qu'ils sont censés être, toujours selon moi, car il est rare que vous lisiez des fichiers à partir du cache, mais les petites écritures, inférieures à la taille de votre cache, sembleront être super rapides alors qu'en fait le lecteur écrira ce cache sur NAND tôt ou tard.

Edit : Voir ci-dessous la suggestion de Sandbo d'utiliser KDiskMark qui est disponible sous forme de package snap.

sudo snap install kdiskmark

KDiskMark fonctionne très bien, bien mieux que le banc de disques intégré.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X