Journal HOW TO : Bench this SSD

Posté par  . Licence CC By‑SA.
Étiquettes :
17
23
mai
2017

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 (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

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

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.

  • # gnome-disks

    Posté par  . Évalué à 8.

    Pour info, gnome-disks (qui permet d'autre trucs sympa comme le montage d'images de disque) à un outil de performance intégré :
    gnome-disks bench

    Ça m'avait permis de tester rapidement mon SSD sur un vieux portable, j'avais même poussé le vis en le branchant avec le caddy IDE/SATA qui remplaçait mon lecteur DVD.

    • [^] # Re: gnome-disks

      Posté par  . Évalué à 2.

      Peut-on dire que c'est à peu de chose près la même chose que le visualizer de fio ? https://github.com/01org/fiovisualizer

    • [^] # Re: gnome-disks

      Posté par  (Mastodon) . Évalué à 6.

      le vice.

    • [^] # Re: gnome-disks

      Posté par  . Évalué à 3.

      la vis.

      *splash!*

      • [^] # Re: gnome-disks

        Posté par  (site web personnel) . Évalué à 1.

        Ici, pays de la Chocolatine, on dit «un vis».
        Je n'ai jamais compris pourquoi.

        « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

        • [^] # Re: gnome-disks

          Posté par  . Évalué à 4.

          Un vis ou un vit ? :)

        • [^] # Re: gnome-disks

          Posté par  . Évalué à 5. Dernière modification le 25 mai 2017 à 08:59.

          Ici, pays de la Chocolatine, on dit «un vis».
          Je n'ai jamais compris pourquoi.

          C'est normal, le français ce n'est pas votre langue. Arrêtez de vous faire du mal. Vous c'est l'occitan.

  • # variabilité physique

    Posté par  . Évalué à 3. Dernière modification le 24 mai 2017 à 03:04.

    Pour avoir fait subir à mes 2 SSD en raid0 de pareils tests (moins poussés toutefois) avec dd,
    puis abandonné l'idée du raid, vu les performances qui s'effondraient et restaient en-deçà
    d'un disque simple (l'explication si je me souviens bien serait la bande passante indiquée par smartctl plus haut),
    les 2 disques étant monté sur le même connecteur à la carte mère,
    je m'interroge sur la distribution des accès physique des SSD.

    En effet, sur ce disque monté donc seul sur la nappe, je m'étais aperçu qu'en reproduisant des tests avec dd (ou mv ou rsync),
    les délais s'allongeaient et les performances diminuaient.

    Je n'avais pas creusé sur les raisons de ces baisses de performance, n'étant pas spécialiste.

    Peut-être cela peut s'expliquer par :
    - mon incompétence
    - une logique du SSD
    - des commandes inappropriées
    - des caches du linux qui parasitaient mon test, qui auraient peut-être du être effectués en INIT 1.
    - une usure naturelle du media neuf, au bout de quelques jours…

    egg:
    dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
    256+0 enregistrements lus
    256+0 enregistrements écrits
    268435456 octets (268 MB) copiés, 0,426325 s, 630 MB/s
    dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
    256+0 enregistrements lus
    256+0 enregistrements écrits
    268435456 octets (268 MB) copiés, 1,56507 s, 172 MB/s
    dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
    256+0 enregistrements lus
    256+0 enregistrements écrits
    268435456 octets (268 MB) copiés, 1,54366 s, 174 MB/s
    :~$ dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
    256+0 enregistrements lus
    256+0 enregistrements écrits
    268435456 octets (268 MB) copiés, 2,20899 s, 122 MB/s

    Aussi une question s'ajoute à ces constatations : est-il judicieux d'utiliser un ssd
    - pour la swap
    - pour toute autre utilisation permettant
    . - d'alléger la RAM
    . - ou accélérer des traitements (/tmp)
    Ce :
    - d'une part d'un point de vue des performances,
    - mais aussi d'un point de vue de la fiabilité du support ainsi sollicité.

    PS : n'ayant pas lu l'intégralité de l'article, vu le boulot qui m'attend,
    et je m'en excuse vu sa qualité, il est possible que des éléments de réponse y soient contenus.

    • [^] # Re: variabilité physique

      Posté par  (site web personnel) . Évalué à 4.

      Aussi une question s'ajoute à ces constatations : est-il judicieux d'utiliser un ssd
      - pour la swap

      Avec les SSD actuels, d'après les retours de tests intensifs des constructeurs et indépendants, ton SSD tiendra même avec un swap dessus en terme de fiabilité. Niveau performance cela est bien meilleur qu'un disque dur (ta machine est moins à genoux).

      Après si tu swapes régulièrement, il peut être judicieux d'augmenter ta quantité de RAM, ce sera plus confortable à l'usage et peut te libérer la partition dédiée à la swap si tu n'hibernes jamais ta machine. Ce n'est pas très cher.

      • pour toute autre utilisation permettant . - d'alléger la RAM . - ou accélérer des traitements (/tmp)

      Il est préférable d'utiliser au maximum la RAM pour des raisons de performances, ne mettre sur le SSD que ce qui est trop gros pour y être maintenu en RAM (typiquement si tu as une compilation un peu grosse pour un tmpfs en RAM).

      • [^] # Re: variabilité physique

        Posté par  . Évalué à 1.

        Voici les données brutes :

        dd if=/dev/zero of=/raid_sata/swap_256Mo.dd bs=1M count=256
        256+0 enregistrements lus
        256+0 enregistrements écrits
        268435456 octets (268 MB) copiés, 0,926959 s, 290 MB/s
        dd if=/dev/zero of=/raid_sata/swap_256Mo.dd bs=1M count=256
        256+0 enregistrements lus
        256+0 enregistrements écrits
        268435456 octets (268 MB) copiés, 0,882427 s, 304 MB/s
        dd if=/dev/zero of=/raid_sata/swap_256Mo.dd bs=1M count=256
        256+0 enregistrements lus
        256+0 enregistrements écrits
        268435456 octets (268 MB) copiés, 0,870653 s, 308 MB/s
        dd if=/dev/zero of=/raid_sata/swap_256Mo.dd bs=1M count=256
        256+0 enregistrements lus
        256+0 enregistrements écrits
        268435456 octets (268 MB) copiés, 0,815218 s, 329 MB/s

        dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
        256+0 enregistrements lus
        256+0 enregistrements écrits
        268435456 octets (268 MB) copiés, 0,464421 s, 578 MB/s
        dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
        256+0 enregistrements lus
        256+0 enregistrements écrits
        268435456 octets (268 MB) copiés, 1,68271 s, 160 MB/s
        dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
        256+0 enregistrements lus
        256+0 enregistrements écrits
        268435456 octets (268 MB) copiés, 1,69978 s, 158 MB/s
        :~$ dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
        256+0 enregistrements lus
        256+0 enregistrements écrits
        268435456 octets (268 MB) copiés, 1,65426 s, 162 MB/s

        A noter : raid_sata est sur la même nappe.

        • [^] # Re: variabilité physique

          Posté par  . Évalué à 4.

          Là, tu écris. Sur du RAID 1, quand tu écris, tu dois écrire simultanément (ou presque) sur les deux disques. C’est donc normal que l’écriture RAID soit 2× plus lente.
          En lecture (tu n’as pas fait le test) tu peux espérer au moins la même vitesse. Tu peux gagner si tes deux disques ne sont pas sur la même nappe et donc peuvent faire des lectures parallèles (la moitié des données sur chaque disque).

          Par contre, sur tes chiffres, je ne m’explique pas la variation lié aux écritures suivantes… peut-être le FS qui essaye de pas fractionner les fichiers ? De réécrire dans un fichier existant ?

          • [^] # Re: variabilité physique

            Posté par  . Évalué à 2.

            Là, tu écris. Sur du RAID 1, quand tu écris, tu dois écrire simultanément (ou presque) sur les deux disques. C’est donc normal que l’écriture RAID soit 2× plus lente.

            En lecture (tu n’as pas fait le test) tu peux espérer au moins la même vitesse. Tu peux gagner si tes deux disques ne sont pas sur la même nappe et donc peuvent faire des lectures parallèles (la moitié des données sur chaque disque).

            On peut supposer que les 2 écritures seront parallélisées et donc que la vitesse sera identique. Ce que dit wikipedia est intéressant :

            Any read request can be serviced and handled by any drive in the array; thus, depending on the nature of I/O load, random read performance of a RAID 1 array may equal up to the sum of each member's performance,[a] while the write performance remains at the level of a single disk. However, if disks with different speeds are used in a RAID 1 array, overall write performance is equal to the speed of the slowest disk.[14][15]

            Synthetic benchmarks show varying levels of performance improvements when multiple HDDs or SSDs are used in a RAID 1 setup, compared with single-drive performance. However, some synthetic benchmarks also show a drop in performance for the same comparison.

            En résumé, lecture : somme des vitesses des disques, écriture : vitesse du disque le plus lent.

            • [^] # Re: variabilité physique

              Posté par  . Évalué à 2.

              En résumé, lecture : somme des vitesses des disques, écriture : vitesse du disque le plus lent

              Ce qui est faux. Si les disques sont sur un même bus, la vitesse maximum en lecture ou écriture ne peux dépasser la vitesse du bus (et si c'est en écriture, c'est la moitié de la vitesse du bus vu que les informations transitent deux fois). (c'est aussi valable avec un seul disque bien sûr mais on atteint moins vite les limites dans ce cas)

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: variabilité physique

                Posté par  . Évalué à 2.

                Je suis d'accord sur le principe.
                Cela dit j'ai vérifié car j'ai besoin de savoir quelles sont les limites en réalité.
                Dernière vérification il y a environ 2 ans, les tests sont ci-dessous.

                Les tests sont fait avec dd, sur les disques bruts ou les partitions brutes, donc sans passer par le système de fichiers.

                Carte-mère à 50 € TTC à l'époque (ASRock H81M-DGS) avec un Celeron, 4 disques mécaniques SATA lus en même temps ont le même débit que s'ils sont lus un par un. C'était des disque à environ 180 Mo/s à l'extérieur des plateaux, soit 720 Mo/s au total. Idem en écriture, mais un poil plus lent. Par contre en les mettant en RAID6 logiciel (mdadm) on n'a que le double du débit, comme si le noyau ne fait qu'une seule lecture à la fois.

                Également testé avec une carte PCIe pas chère ayant 2 ports SATA : zéro ralentissement.
                Puis 4 disques sur la carte-mère + 2 disque sur la carte PCIe, toujours aucun ralentissement.

                Autre carte-mère ordinaire, test avec 4 SSD SATA dont j'ai oublié le débit, même résultat, aucun ralentissement en lecture ou en écriture.

                Sur une carte-mère de serveur avec 9 disques SATA (4 HDD + 5 SSD) branchés sur un contrôleur SAS 16 ports (ou 2 contrôleurs 8 ports, je ne sais plus), zéro ralentissement également. Je n'avais pas le temps de faire un test en récupérant des disques et une alimentation pour utiliser les 16 ports SAS + 6 ports SATA.
                Le RAID matériel de la carte-mère était nul. J'ai testé 4 disques en RAID1, on n'était même pas au double du débit.

  • # /dev/urandom

    Posté par  (site web personnel) . Évalué à 9.

    Le facteur limitant quand tu copies /dev/urandom, c'est ton processeur qui n'arrive pas à calculer des nombres aléatoires suffisamment rapidement.

    • [^] # Re: /dev/urandom

      Posté par  (Mastodon) . Évalué à 6.

      En effet, sur mon i7 6700K (on peut pas dire que ce soit une croûte)

      cat /dev/urandom | pv > /dev/null
      => 18GiO 0:00:10 [ 224MiB/s]

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: /dev/urandom

      Posté par  . Évalué à 3.

      Effectivement, faire un test de performance disque en utilisant les données issues de /dev/urandom (ou pire de /dev/random) n'est pas vraiment pertinent en raison de la vitesse de génération de ces données pseudo-aléatoires.
      D'un autre côté, utiliser /dev/zero ne me semble pas pertinent non plus, puisque c'est la même donnée qui se répète dans tous le fichier.
      Un voie possible pourrait être d'utiliser /dev/urandom pour créer un gros fichier sur un système de fichiers en RAM (/dev/shm par exemple) et de prendre ce fichier comme source pour l'écriture sur le disque à tester. Mais même dans ce cas, le résultat peut être biaisé en raison des optimisations faites par l'OS (cache en lecture, même si avec un fichier en RAM ça ne doit pas jouer, et bufferisation des écritures [je ne sais pas comment dd gère cela]).

      Sinon, il existe aussi la commande hdparm qui, avec l'option «-t», permet de se faire une idée des performances en lecture du disque.

  • # Attention aux unités…

    Posté par  . Évalué à 10.

    L’interface disque <--> CPU fait 6Gb/s maximum, le « b » est minuscule, ce qui veut dire bits, alors que dd te renvoie un résultat en MB/s ou GB/s, ici le « B » est majuscule signifie Byte ou octet.

    1B == 8b. Donc ton interface ne peut pas aller au delà de 6000/8 = 750MB/s. Donc si tu vas plus vite que ça, ça veut dire que tu lis directement en RAM dans le cache disque de linux.

  • # Le cache du noyau

    Posté par  (site web personnel) . Évalué à 3.

    Attention au cache du noyau, qui fait du writeback. (Avec une VM, cache du driver VirtIO par ex).

    Il est préférable de tester avec 2× la taille de sa RAM. Écrire et lire un fichier de 2×RAM.
    Les résultats seront très différents ;)

  • # iozone

    Posté par  . Évalué à 2. Dernière modification le 24 mai 2017 à 11:23.

    Comme outil de benchmark y'a aussi iozone.

    Certains fabricants l'ont utilisé lors de leurs présentations de produit, ça en fait un programme assez connu de la communauté geek même hors Linux.

    • [^] # Re: iozone

      Posté par  (site web personnel) . Évalué à -2.

      Certains fabricants l'ont utilisé lors de leurs présentations de produit …

      Ça ressemble plus à un outil de marketing qu'un benchmark.

      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

    • [^] # Re: iozone

      Posté par  (site web personnel) . Évalué à 2.

      Voire aussi : Bonnie++

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Ça mesure le débit du FS !

    Posté par  . Évalué à 5.

    En faisant des dd comme ça, tu ne mesures pas la vitesse des I/O de ton média, mais de toute ta chaine vers ton FS: la maj des caches + inodes + FS + … + IO vers ton SSD.

    Je pense qu'il faudrait les refaire sur le disque directement (dd if=/dev/zero of=/dev/sda). Mais bon, là tu fout en vrac tes partitions et tes donnés !

  • # Mesurer les I/O aléatoires et de tailles multiples

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Personnellement je préfère m'intéresser aux I/O selon leurs tailles (en particulier les petites) et pas forcément séquentielles. Parce que je sais qu'à moins d'un défaut grave, le cas mesuré par dd (I/O de grandes tailles et séquentielles) ne vont pas poser problème.

    Un outil pratique pour ça, c'est iops (qui a un nom pourri pour le retrouver sur le net) et qui produit ce genre de résultats :

    Mon SSD

    $ sudo ./iops /dev/sda
/dev/sda, 256.06 G, sectorsize=512B, #threads=32, pattern=random:
 512  B blocks: 97194.1 IO/s,  49.8 MB/s (398.1 Mbit/s)
   1 kB blocks: 67929.4 IO/s,  69.6 MB/s (556.5 Mbit/s)
   2 kB blocks: 44446.0 IO/s,  91.0 MB/s (728.2 Mbit/s)
   4 kB blocks: 26299.0 IO/s, 107.7 MB/s (861.8 Mbit/s)
   8 kB blocks: 25971.7 IO/s, 212.8 MB/s (  1.7 Gbit/s)
  16 kB blocks: 15269.8 IO/s, 250.2 MB/s (  2.0 Gbit/s)
  32 kB blocks: 8157.7 IO/s, 267.3 MB/s (  2.1 Gbit/s)
  65 kB blocks: 4314.4 IO/s, 282.7 MB/s (  2.3 Gbit/s)
 131 kB blocks: 2295.6 IO/s, 300.9 MB/s (  2.4 Gbit/s)
 262 kB blocks: 1475.4 IO/s, 386.8 MB/s (  3.1 Gbit/s)
 524 kB blocks:  894.7 IO/s, 469.1 MB/s (  3.8 Gbit/s)
   1 MB blocks:  502.1 IO/s, 526.5 MB/s (  4.2 Gbit/s)
   2 MB blocks:  265.6 IO/s, 557.1 MB/s (  4.5 Gbit/s)
   4 MB blocks:  138.8 IO/s, 582.1 MB/s (  4.7 Gbit/s)
   8 MB blocks:   69.6 IO/s, 583.4 MB/s (  4.7 Gbit/s)
  16 MB blocks:   35.6 IO/s, 597.0 MB/s (  4.8 Gbit/s)
  33 MB blocks:   17.7 IO/s, 593.3 MB/s (  4.7 Gbit/s)
  67 MB blocks:    8.6 IO/s, 575.1 MB/s (  4.6 Gbit/s)
 134 MB blocks:    4.4 IO/s, 591.8 MB/s (  4.7 Gbit/s)

    Sur mon HDD 7200 rpm

    $ sudo ./iops /dev/sdb
/dev/sdb, 500.11 G, sectorsize=4096B, #threads=32, pattern=random:
 512  B blocks:  105.8 IO/s,  54.2 kB/s (433.4 kbit/s)
   1 kB blocks:  113.4 IO/s, 116.1 kB/s (928.7 kbit/s)
   2 kB blocks:  122.8 IO/s, 251.5 kB/s (  2.0 Mbit/s)
   4 kB blocks:  127.2 IO/s, 521.1 kB/s (  4.2 Mbit/s)
   8 kB blocks:  126.1 IO/s,   1.0 MB/s (  8.3 Mbit/s)
  16 kB blocks:  125.8 IO/s,   2.1 MB/s ( 16.5 Mbit/s)
  32 kB blocks:  122.5 IO/s,   4.0 MB/s ( 32.1 Mbit/s)
  65 kB blocks:  120.6 IO/s,   7.9 MB/s ( 63.2 Mbit/s)
 131 kB blocks:  117.2 IO/s,  15.4 MB/s (122.9 Mbit/s)
 262 kB blocks:   66.8 IO/s,  17.5 MB/s (140.2 Mbit/s)
 524 kB blocks:   38.4 IO/s,  20.1 MB/s (161.0 Mbit/s)
   1 MB blocks:   25.9 IO/s,  27.2 MB/s (217.3 Mbit/s)
   2 MB blocks:   15.0 IO/s,  31.5 MB/s (252.1 Mbit/s)
   4 MB blocks:   10.6 IO/s,  44.4 MB/s (355.5 Mbit/s)
   8 MB blocks:    5.5 IO/s,  46.2 MB/s (369.8 Mbit/s)

    Et pour le fun, sur la RAM (test limité par le CPU)

    $ sudo ./iops /dev/ram0
/dev/ram0, 126.42 M, sectorsize=4096B, #threads=32, pattern=random:
 512  B blocks: 169253.2 IO/s,  86.7 MB/s (693.3 Mbit/s)
   1 kB blocks: 170916.2 IO/s, 175.0 MB/s (  1.4 Gbit/s)
   2 kB blocks: 169963.8 IO/s, 348.1 MB/s (  2.8 Gbit/s)
   4 kB blocks: 171712.1 IO/s, 703.3 MB/s (  5.6 Gbit/s)
   8 kB blocks: 166601.5 IO/s,   1.4 GB/s ( 10.9 Gbit/s)
  16 kB blocks: 165693.6 IO/s,   2.7 GB/s ( 21.7 Gbit/s)
  32 kB blocks: 155599.9 IO/s,   5.1 GB/s ( 40.8 Gbit/s)
  65 kB blocks: 135273.5 IO/s,   8.9 GB/s ( 70.9 Gbit/s)
 131 kB blocks: 73579.7 IO/s,   9.6 GB/s ( 77.2 Gbit/s)
 262 kB blocks: 35860.6 IO/s,   9.4 GB/s ( 75.2 Gbit/s)
 524 kB blocks: 17558.8 IO/s,   9.2 GB/s ( 73.6 Gbit/s)
   1 MB blocks: 8830.1 IO/s,   9.3 GB/s ( 74.1 Gbit/s)
   2 MB blocks: 4505.4 IO/s,   9.4 GB/s ( 75.6 Gbit/s)
   4 MB blocks: 2426.2 IO/s,  10.2 GB/s ( 81.4 Gbit/s)
   8 MB blocks: 1263.4 IO/s,  10.6 GB/s ( 84.8 Gbit/s)
  16 MB blocks:  668.7 IO/s,  11.2 GB/s ( 89.8 Gbit/s)
  33 MB blocks:  239.9 IO/s,   8.0 GB/s ( 64.4 Gbit/s)
  67 MB blocks:   65.7 IO/s,   4.4 GB/s ( 35.3 Gbit/s)

    La connaissance libre : https://zestedesavoir.com

  • # fio - Flexible IO Tester

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 26 mai 2017 à 22:39.

    ici

    https://git.kernel.org/pub/scm/linux/kernel/git/axboe/fio.git/

    ce qu il faut faire aussi quand on teste les io, c'est de vérifier/ mettre les cache divers et varié hors scope, c est a dire de faire du directio.

    comprendre que si tu faits des écriture de ficher de 1Go et que tu as 8 ou
    Go de ram , bah tu risque de surtout bencher ta ram :)

    après avec les couches FS, et les caches FS/ kernel … tu bench pas grand chose. donc il te faut travailler avec des fichiers de tailles > RAM, ou en directio

    fio a pas mal de fichiers de conf pour tester et grapher les SSD que ca soit en mode raw ou avec des file systemes et avec la gestion des cache, du directio, en mode séquentiel ou aléatoire suivant ton besoin. :)

    ensuite bencher les io est qq chose de beaucoup plus complexe qu il n y parait, et je ne m étendrais pas sur le sujet car je suis certain de lancer ensuite des bon gros troll bien velus

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.