URL: https://linuxfr.org/users/xunfr/journaux/how-to-bench-this-ssd Title: HOW TO : Bench this SSD Authors: xunfr Date: 2017年05月23日T23:22:42+02:00 License: CC By-SA Tags: benchmark, ssd et testdisk Score: 17 Salutations Bon, voilà, j'ai voulu voir ce que pouvait donner un petit bench (test de performances) sur mon SSD, histoire de me familiariser avec les outils à disposition pour le faire, et également dans un but de découverte. - **Conditions de tests** A ma disposition, j'ai donc un disque SSD de capacité 256 Go, et de marque Transcend. Avec plus de détails via la commande smartctl (dispo via le paquet smartmontools): sudo smartctl -a /dev/sda Device Model: TS256GSSD370S Serial Number: C571740122 Firmware Version: O0919A User Capacity: 256 060 514 304 bytes [256 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ACS-2 (minor revision not indicated) SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) J'ai pas mis la totalité des informations retournés, mais ces quelques lignes sont déjà importantes. Notamment la vitesse théorique du port SATA qui est de 6 G/s. Vu la version (3.1), on sait qu'on a affaire à du [mSATA](https://fr.wikipedia.org/wiki/Serial_ATA#R.C3.A9vision_3.1_ou_mSATA) (adaptation du SATA destinée aux portables, SSD...). Le débit théorique sera difficilement atteignable, on va donc plutôt parler de débit crête pratique qui va se situer pour ce modèle aux alentours de 600 Mo/s (comme on le voit plus bas). - **Tests du SSD en écriture** Pour les premiers tests, je vais me baser sur la commande « dd » très souvent utilisée lorsque l'on parle de bench. On va utiliser un fichier de 1G (1024 bloc de 1M) : dd if=/dev/zero of=tempfile bs=1M count=1024 1024+0 enregistrements lus 1024+0 enregistrements écrits 1073741824 octets (1,1 GB) copiés, 3,39989 s, **316 MB/s** On a donc écrit ce fichier en 3.39s, ce qui nous a donné une vitesse d’écriture de 316M/s. C'est pas mal, même si on est assez loin des 600. Pour info, le fichier a été écrit sur une partition utilisateur (home), donc pas nécessairement perturbé par des processus I/O. J'ai voulu faire la même chose sur une partition virtualisée pour voir si on avait le même type de performance : dd if=/dev/zero of=tempfile bs=1M count=1024 1024+0 enregistrements lus 1024+0 enregistrements écrits 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 1,82052 s, **590 MB/s** Non mais ! Pas d'excitation, même s'il est vrai que le débit est excellent... Ce qu'on peut déjà souligné, c'est que le fait de lancer ma copie « dd » sur une VM n'a pas plus d'incidence que sur ma session hôte. Par contre, là où il ne fallait pas s'étonner, c'est sur le débit. En effet, le débit est extrêmement variable : il me suffit juste de relancer la commande à la suite pour afficher une autre vitesse. J'ai lancé la commande sur 4 passes, pour vérifier que ce n'est pas l'opération précédente qui influençait le résultat : for i in {0..3};do dd if=/dev/zero of=tempfile bs=1M count=1024 conv=sync;done 1024+0 enregistrements lus 1024+0 enregistrements écrits 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 1,91371 s, **561 MB/s** 1024+0 enregistrements lus 1024+0 enregistrements écrits 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 2,60669 s, 412 MB/s 1024+0 enregistrements lus 1024+0 enregistrements écrits 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 1,95611 s, 549 MB/s 1024+0 enregistrements lus 1024+0 enregistrements écrits 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 2,60068 s, 413 MB/s Une remarque au passage... J'ai utilisé ici le périphérique /dev/zero pour générer mon fichier de sortie. Si j'utilise le « urandom » à la place, le débit est nettement plus réduit : dd if=/dev/urandom of=tempfile bs=1M count=1024 1024+0 enregistrements lus 1024+0 enregistrements écrits 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 8,00623 s, **134 MB/s** Autre remarque. Je suis également parti sur le montage d'une partition dédiée avec la désactivation du cache au mount : ext4 sync 0 0 dd if=/dev/zero of=tempfile bs=1M count=1024 1024+0 enregistrements lus 1024+0 enregistrements écrits 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 3,20391 s, **335 MB/s** On constate nettement la perte de débit sur ce type de partition. - **Tests du SSD en lecture** Idem qu'au dessus, toujours avec la commande « dd », et on va jouer sur la taille des blocs : dd if=tempfile of=/dev/null bs=1M 1024+0 enregistrements lus 1024+0 enregistrements écrits 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,235401 s, **4,6 GB/s** dd if=tempfile of=/dev/null bs=512k conv=sync 2048+0 enregistrements lus 2048+0 enregistrements écrits 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,213183 s, **5,0 GB/s** On constate qu'on a pas d'influence sur la taille des blocs, et qu'on est assez proche de la vitesse théorique du port. On va essayer de faire la même chose en vidant cette fois le cache mémoire avant de lire le fichier: sudo sh -c "free && sync && echo 3> /proc/sys/vm/drop_caches && free"; dd if=tempfile of=/dev/null bs=512K total utilisé libre partagé tamp/cache disponible Mem: 1593340 293032 1188332 3272 111976 1167924 Partition d'échange: 1638396 32792 1605604 total utilisé libre partagé tamp/cache disponible Mem: 1593340 291312 1192672 3272 109356 1170944 Partition d'échange: 1638396 32792 1605604 2048+0 enregistrements lus 2048+0 enregistrements écrits 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 2,91954 s, **368 MB/s** Ah oui, effectivement, ca change tout de vider un cache mémoire ! D'un autre côté, ca ne surprend pas tant que çà, c'est un peu le but en perf d'accéder à l'information en priorité sur le cache. Ce que j'ai remarqué également, c'est que même en désactivant le cache via la commande « hdparm », ca me remontait des débits proche du 5G/s. De ce que j'en ai compris, la commande ne désactive que les blocs. Le cache mémoire est de plus haut niveau. La partition dédiée, comme vu plus haut, n'apporte pas de plus par rapport à une partition habituelle : dd if=tempfile of=/dev/null bs=1M 1024+0 enregistrements lus 1024+0 enregistrements écrits 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,227458 s, **4,7 GB/s** - **D'autres alternatives de tests** En dehors de la fameuse commande « dd », il y aurait d'autres façons de mesurer les performances de son SSD, et de façon bien plus détaillé. On va mettre tout ca en pratique... Une des commandes phares, car elle permet d'affiner les variables à prendre en compte lors du bench, et d'afficher en sortie des détails très poussés sur les performances du disque, est la commande « fio ». Vous trouverez bien plus de détails sur le portail git du projet: https://github.com/axboe/fio Appliquons la commande à notre SSD : sudo fio --name=filerand --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=256M --numjobs=4 --runtime=60 --group_reporting En gros, on va générer 4 fichiers filerand d'une taille de 256M chacun (taille du bloc 4K), écrit aléatoirement (comme le /dev/urandom?), soit une opération fio de 1G pour une durée max de 60 secondes. La taille de l'opération ne doit pas excéder la taille de la RAM. Dans mon cas, c'est parfait, puisque j'ai une ram dispo de 1.5G. L'option concernant le moteur d'io utilisé par fio (ioengine) sont couramment soit la libaio, soit la sync (appels asynchrones, ou pas). L'iodepth n'a pas d'importance au délà de « 1 » pour un ioengine en mode synchrone. Après, certains OS limite cette possibilité, donc au final, on commence avec 1, et on peut éventuellement augmenter la valeur. L'option « direct » va essentiellement jouer sur les performances en lecture, soit avec une mise en cache, soit en accès direct. En mettant l'option à « 0 », on va utiliser le cache, et donc améliorer les performances en read. Plus de détails ici : [https://wiki.mikejung.biz/Benchmarking](https://wiki.mikejung.biz/Benchmarking) Parmi les nombreuses lignes de résultat, une des plus importantes à checker est celle-ci : write: io=1024.0MB, bw=45541KB/s, iops=11385, runt= 23025msec Donc, pour résumer, l'opération pour écrire 1G a duré 23s, pour un débit en iops de 11385, soit une vitesse en écriture de **45.54Mb/s**, mais plus précisément(11385 * 4 (taille du bloc) / 1024 = 44.47 Mbs) - Pour le calcul, je me suis basé sur le site : [http://www.ssdfreaks.com/content/599/how-to-convert-mbps-to-iops-or-calculate-iops-from-mbs](http://www.ssdfreaks.com/content/599/how-to-convert-mbps-to-iops-or-calculate-iops-from-mbs) Avec l'option ioengine à « sync », cela nous donne : write: io=1024.0MB, bw=71056KB/s, iops=17764, runt= 14757msec soit un taux de **71Mbs** Pour un fichier plus gros, et donc en augmentant le nombre de jobs à 8, ca se corse : write: io=2048.0MB, bw=42642KB/s, iops=10660, runt= 49181msec soit un taux de **42.64Mbs** Il y a énormément d'options, ce sera difficile de tout détailler ici, mais je vous conseille d'aller faire un tour sur le git, et d'essayer sur vos disques. Par contre, on voit bien l'intérêt de tels outils (notamment le fio) lorsque l'on désire vérifier le bon fonctionnement du disque, avant d'impacter la cause d'un ralentissement à des processus trop gourmands (bien que cela peut effectivement jouer). Mais c'est plus dans le sens d'analyse de l'état d'un périphérique avant d'en demander la maintenance.

AltStyle によって変換されたページ (->オリジナル) /