SSD diagnostique statique/rotatif Le sujet est résolu

[dezix]

Bonjour,

Encore avec le VPS d'OVH,
qui est vendu comme "SSD1" (c'était le nom du produit)

Avant d'activer le TRIMming,
je vérifie la détection du SSD :

Code : Tout sélectionner

# cat /sys/block/sda/queue/rotational
1

Le disque est donc vu comme rotatif


Ce qui est confirmé par :

Code : Tout sélectionner

# lsblk -d -o name,rota /dev/sda
NAME ROTA
sda     1


# cat /sys/class/block/sda/queue/rotational
1


# lshw -class disk
  *-disk                    
       description: SCSI Disk
       produit: QEMU HARDDISK
       fabriquant: QEMU
       identifiant matériel: 0.0.0
       information bus: scsi@2:0.0.0
       nom logique: /dev/sda
       version: 2.5+
       taille: 20GiB (21GB)
       fonctionnalités: 5400rpm partitioned partitioned:dos
       configuration: ansiversion=5 logicalsectorsize=512 sectorsize=512

Sur le forum OVH un utilisateur me dit que le serveur hébergeant le VPS est équipé de SSD,
et que c'est l'émulation qui affiche un HDD ... je me demande bien pourquoi !

Un autre m'a conseillé des comparaisons sur la base des tests suivants :

Code : Tout sélectionner

# hdparm -t /dev/sda
/dev/sda:
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 Timing buffered disk reads: 578 MB in  3.01 seconds = 191.73 MB/sec
 

Noter que la réponse est très variable allant de 39.22 MB/sec à 262.48 MB/sec

La 1ère exécution de la commande a donnée le résultat le plus bas,
puis il est monté à 200 MB/s continuant à grimper les 3 ou 4 fois suivantes,
puis retombé à 50 MB/s et ainsi de suite.


Pour comparaison, le même test fait sur mes machines donne des résultats stables :
* 235 MB/s pour un SSD
* 75 MB/s pour un HDD à 7200rpm

et

# hdparm --direct -t /dev/sda

renvoie 9/10 400 MB/s avec 1/10 tombant à 200/300 MB/s


Puis

Code : Tout sélectionner

# hdparm -T /dev/sda
/dev/sda:
 Timing cached reads:   13312 MB in  1.99 seconds = 6681.29 MB/sec

donc le résultat varie entre 6500 et 7000 MB/s

Le même test fait sur mes machines donne des résultats stables :
* 2140 MB/s pour un SSD
* 670 MB/s pour un HDD à 7200rpm



Je vous demande votre avis sur cette situation
et
vous semble-t-il une bonne idée d'activer le TRIMming avec :

# systemctl enable fstrim.timer

sachant que pour l'instant :

Code : Tout sélectionner

# systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/lib/systemd/system/fstrim.timer; disabled; vendor preset: enabled)
   Active: inactive (dead)
  Trigger: n/a
     Docs: man:fstrim

[édité]
J'avais oublié :

Code : Tout sélectionner

# systemctl status fstrim.service
● fstrim.service - Discard unused blocks on filesystems from /etc/fstab
   Loaded: loaded (/lib/systemd/system/fstrim.service; static; vendor preset: en
   Active: inactive (dead)
     Docs: man:fstrim(8)

Merci.

[MicP]

Bonjour

Depuis une machine virtuelle QEMU/KVM debian 10 (buster) créée sur un fichier image disque de type qcow2 connecté en virtIO
le tout sur une machine hôte debian 10 (buster) installée sur machine équipée de deux disques SSD :

Code : Tout sélectionner

michel@micvirt:~$ lsblk -d -o+rota /dev/vda 
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ROTA
vda  254:0    0  16G  0 disk               1
michel@micvirt:~$ 

Code : Tout sélectionner

michel@micvirt:~$ cat /sys/class/block/vda/queue/rotational 
1
michel@micvirt:~$ 

Code : Tout sélectionner

michel@micvirt:~$ su -c 'lshw -class disk'
Mot de passe : 
  *-virtio2                 
       description: Virtual I/O device
       identifiant matériel: 0
       information bus: virtio@2
       nom logique: /dev/vda
       taille: 16GiB (17GB)
       fonctionnalités: partitioned partitioned:dos
       configuration: driver=virtio_blk logicalsectorsize=512 sectorsize=512 signature=58b8dcf4
michel@micvirt:~$

[piratebab]

Dezix, tu ne vois le disque qu'a travers qemu, tu n'as pas accès physiquement au disque, tu ne peux pas optimiser son utilisation.
Le debit est fortement variable, tout dépends de l'activité des autres VM de l'jote.

[PascalHambourg]

Comme ça a déjà été dit, c'est un disque virtuel, pas un SSD ni un disque dur. Le stockage sous-jaçent peut être n'importe quoi : un fichier image disque, un volume logique, une "partition" d'infrastructure de stockage SAN ou SAS, sur des disques durs, des SSD, des disques durs avec un cache sur SSD... partagés avec d'autres VPS donc les performances varient en function de l'activité de celles-ci.

Ce n'est pas en regardant si c'est un disque est rotatif que tu verras s'il supporte le trim/discard. Ce sont deux caractéristiques indépendantes. Le trim/discard peut se retrouver sur des supports de stockage autres que les SSD comme les disques durs à technologie SMR ou les volumes logiques en "thin provisioning". Si le disque virtuel supporte le trim/discard et le transmet au stockage sous-jacent, cela peut être utile pour l'hébergeur du VPS mais probablement pas pour toi.

[dezix]

Merci pour vos réponses,

Je vais suivre le conseil et oublier le TRIMming qui (j'espère) sera fait au niveau du serveur physique.


Pour info, on m'a fourni (communauté OVH) ces 2 commandes de test,
car hdparm ne serait pas trop adapté aux VM d'OVH :

Test d' Écriture

# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_write.fio --bs=4k --iodepth=64 --size=1G --readwrite=randwrite


Test de Lecture

# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_read.fio --bs=4k --iodepth=64 --size=1G --readwrite=randread


J'ai parcouru rapidement le manuel de fio (3000 lignes)
et
apparemment il teste le système globalement (ne cible pas un périphérique de stockage précis)

Les performances du VPS sont bien moindres que celles d'un SSD local ou d'une VBox sur SSD local mais tout de même supérieures à un HDD local.






Si cela peut avoir un quelconque intérêt, voici les résultats de ces tests :

Écriture

VPS OVH

Code : Tout sélectionner

# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_write.fio --bs=4k --iodepth=64 --size=1G --readwrite=randwrite
test: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.12
Starting 1 process
test: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [w(1)][100.0%][w=3971KiB/s][w=992 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=23245: Tue Aug 11 11:20:18 2020
  write: IOPS=958, BW=3833KiB/s (3925kB/s)(1024MiB/273556msec); 0 zone resets
   bw (  KiB/s): min=    8, max= 5080, per=99.99%, avg=3832.59, stdev=578.19, samples=547
   iops        : min=    2, max= 1270, avg=958.14, stdev=144.54, samples=547
  cpu          : usr=0.94%, sys=4.74%, ctx=258311, majf=0, minf=8
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0%
     issued rwts: total=0,262144,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
  WRITE: bw=3833KiB/s (3925kB/s), 3833KiB/s-3833KiB/s (3925kB/s-3925kB/s), io=1024MiB (1074MB), run=273556-273556msec

Disk stats (read/write):
    dm-0: ios=0/372679, merge=0/0, ticks=0/25226216, in_queue=25228252, util=100.00%, aggrios=0/271113, aggrmerge=0/102034, aggrticks=0/17392085, aggrin_queue=17342664, aggrutil=99.68%
  sda: ios=0/271113, merge=0/102034, ticks=0/17392085, in_queue=17342664, util=99.68%

Tests locaux

Code : Tout sélectionner

#SSD#

  WRITE: bw=109MiB/s (114MB/s), 109MiB/s-109MiB/s (114MB/s-114MB/s), io=1024MiB (1074MB), run=9378-9378msec

#VBox sur SSD#

  WRITE: bw=13.5MiB/s (14.1MB/s), 13.5MiB/s-13.5MiB/s (14.1MB/s-14.1MB/s), io=1024MiB (1074MB), run=75966-75966msec

#HDD#

WRITE: bw=831KiB/s (851kB/s), 831KiB/s-831KiB/s (851kB/s-851kB/s), io=1024MiB (1074MB), run=1262199-1262199msec

Lecture

VPS OVH

Code : Tout sélectionner

# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_read.fio --bs=4k --iodepth=64 --size=1G --readwrite=randread
test: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.12
Starting 1 process
test: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [r(1)][100.0%][r=4004KiB/s][r=1001 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=24078: Tue Aug 11 12:19:00 2020
  read: IOPS=999, BW=3999KiB/s (4095kB/s)(1024MiB/262216msec)
   bw (  KiB/s): min= 3528, max= 4616, per=100.00%, avg=3998.52, stdev=75.03, samples=524
   iops        : min=  882, max= 1154, avg=999.62, stdev=18.75, samples=524
  cpu          : usr=1.00%, sys=3.43%, ctx=200804, majf=0, minf=71
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0%
     issued rwts: total=262144,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=3999KiB/s (4095kB/s), 3999KiB/s-3999KiB/s (4095kB/s-4095kB/s), io=1024MiB (1074MB), run=262216-262216msec

Disk stats (read/write):
    dm-0: ios=262034/31, merge=0/0, ticks=16752744/468, in_queue=16755512, util=100.00%, aggrios=262199/150, aggrmerge=0/113, aggrticks=16768503/2070, aggrin_queue=16685912, aggrutil=99.49%
  sda: ios=262199/150, merge=0/113, ticks=16768503/2070, in_queue=16685912, util=99.49%

Tests locaux

Code : Tout sélectionner

# SSD#

   READ: bw=232MiB/s (243MB/s), 232MiB/s-232MiB/s (243MB/s-243MB/s), io=1024MiB (1074MB), run=4415-4415msec


#VBox sur SSD#

   READ: bw=42.6MiB/s (44.6MB/s), 42.6MiB/s-42.6MiB/s (44.6MB/s-44.6MB/s), io=1024MiB (1074MB), run=24054-24054msec

#HDD#

READ: bw=973KiB/s (996kB/s), 973KiB/s-973KiB/s (996kB/s-996kB/s), io=1024MiB (1074MB), run=1077804-1077804msec

[PascalHambourg]

Je vais suivre le conseil et oublier le TRIMming qui (j'espère) sera fait au niveau du serveur physique.

Je ne vois pas comment. L'information de TRIM/discard doit descendre du niveau le plus haut (système de fichiers) au niveau le plus bas (matériel) car seul le premier a connaissance de l'occupation réelle des blocs et seul le dernier peut l'exploiter. S'il manque un seul maillon de la chaîne, alors ça ne marche pas.

[dezix]

Je ne vois pas comment.

Moi non plus,
mais vu que l'OS voit le disque comme rotatif,
je supposais qu'il ne ferait pas de trim sur un tel périphérique,
et que si optimisation il y a,
ce serait fait en amont pour fournir le meilleur service -- on a le droit d'y croire ?

en plus, après :

cela peut être utile pour l'hébergeur du VPS mais probablement pas pour toi.

je ne croyais plus à un quelconque intérêt
ou pire même,
créer un conflit avec des instructions contradictoires à la détection du matériel.

J'ai recherché un moyen de déterminer si un périphérique de stockage supporte ou non le "trim",
à part si c'est clairement annoncé dans la doc du matos,
je n'ai rien trouvé :((

FINALEMENT,
j'ai fait une entorse à ma règle de prudence N°1 : "Tu ne testeras pas des trucs au PIF !"
en faisant :

Code : Tout sélectionner

# fstrim -av
/srv/db: 961,7 MiB (1008386048 bytes) trimmed on /dev/mapper/vg0-lv_srv_db
/var/cache: 267,6 MiB (280596480 bytes) trimmed on /dev/mapper/vg0-lv_var_cache
/home: 284,4 MiB (298202112 bytes) trimmed on /dev/mapper/vg0-lv_home
/var/log: 38,2 MiB (40069120 bytes) trimmed on /dev/mapper/vg0-lv_var_log
/tmp: 376,6 MiB (394891264 bytes) trimmed on /dev/mapper/vg0-lv_tmp
/srv/ftp: 965,8 MiB (1012744192 bytes) trimmed on /dev/mapper/vg0-lv_srv_ftp
/srv/http: 1,9 GiB (2024505344 bytes) trimmed on /dev/mapper/vg0-lv_srv_http
/srv/mail: 965,8 MiB (1012744192 bytes) trimmed on /dev/mapper/vg0-lv_srv_mail
/boot: 76,7 MiB (80404480 bytes) trimmed on /dev/sda1
/: 412,4 MiB (432451584 bytes) trimmed on /dev/mapper/vg0-lv_racine

J'ai apparemment de la chance, on dirait que ça a "trimmer" correctement et sans casse


Juste une dernière question (bête) :

Avec ce disk un peu "zarbi"
il vaudrait mieux :

systemctl enable fstrim.timer
ou
créer une tâche cron.weekly avec fstrim --all

ou c'est kifkif ?

[dezix]

Pour récapituler et vérifier ma compréhension :

Donc — à peu près —

l'écriture des données sur le disque se fait presque en temps réel,
(presque car en fait l'application modifie une copie des données en RAM,
ces données modifiées remplaçant ensuite les données sources sur le disque),

alors que la suppression des données n'est (dans un premier temps qui peut durer)
qu'une opération logicielle sur des tables et des index du système de fichiers,
les données correspondantes sur le disque n'étant pas remises à "zéro".

Pour un HDD,
les secteurs peuvent être récrits directement en écrasant les anciennes données,
le système de fichiers n'a donc pas à informer le disque des suppressions.
Il indique simplement que tel secteur est libre et que l'on peut y écrire.

Pour un SSD,
avant de pouvoir écrire à nouveau sur un espace (pages) qui n'est plus utilisé par le système de fichiers,
il faut récrire les blocs complets (groupes de pages) qui les contiennent pour libérer les pages qui n'y sont plus utilisées.

Le trim est un mécanisme supplémentaire qui informe le matériel des suppressions qui ont eu lieu depuis sa dernière exécution.

Cette opération périodique permet de maintenir le stock des blocs disponibles pour l'écriture, d'où un gain en réactivité pour le système.

Certains SSD (source Intel) disposent d'une "rallonge" d'espace interne dédiée à cette tâche (de réécriture) non-comptabilisée dans la capacité annoncée.

J'ai aussi lu que ne pas allouer une fraction de sa capacité peut améliorer le fonctionnement du SSD
en lui garantissant un espace libre suffisant pour les opérations de gestion ; je ne suis pas certain de cela.