Lenteurs lecture / ecriture sur SSD (d'après zabbix)

Support Debian
,
Tags: #<Tag:0x00007f509f290e90> #<Tag:0x00007f509f290bc0>
#1

salut,

j’ai monté un serveur (web et autre) avec un intel nuc sous buster. le système est installé sur un SSD (sda).

je le supervise avec zabbix (depuis lui-même sous docker) et que j’ai configuré avec le modèle Template OS Linux by Zabbix agent.

zabbix me remonte cette alerte :

sda: Disk read/write request response are too high (read > 20 ms for 15m or write > 20 ms for 15m)
this trigger might indicate disk sda saturation.

a priori j’ai jamais rencontré de lenteur particulière sur ce système, mais j’ai fait quelques tests :

espace libre :

krodelabestiole@micropoutre ~  df -h | grep sda
/dev/sda2       102G   51G   47G  53% /
/dev/sda1       511M  5.2M  506M   1% /boot/efi

dd :

krodelabestiole@micropoutre ~  sudo dd if=/dev/zero of=/root/testfile bs=512 count=1000 oflag=dsync
1000+0 records in
1000+0 records out
512000 bytes (512 kB, 500 KiB) copied, 239.711 s, 2.1 kB/s

hdparm :

krodelabestiole@micropoutre ~  sudo hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads:   6998 MB in  2.00 seconds = 3505.30 MB/sec
 Timing buffered disk reads: 286 MB in  3.02 seconds =  94.70 MB/sec

smartmon :

krodelabestiole@micropoutre ~  sudo smartctl -H -i /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-6-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Crucial/Micron MX1/2/300, M5/600, 1100 Client SSDs
Device Model:     Crucial_CT120M500SSD3
Serial Number:    1350095E647E
LU WWN Device Id: 5 00a075 1095e647e
Firmware Version: MU03
User Capacity:    120,034,123,776 bytes [120 GB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    Solid State Device
Form Factor:      < 1.8 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 6
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sat Nov  9 17:22:11 2019 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

krodelabestiole@micropoutre ~  sudo smartctl -t short /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-6-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.
Test will complete after Sat Nov  9 17:24:45 2019

Use smartctl -X to abort test.

krodelabestiole@micropoutre ~  sudo smartctl -l selftest /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-6-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%     49944         -
# 2  Vendor (0xff)       Completed without error       00%     41834         -
# 3  Vendor (0xff)       Completed without error       00%      5003         -
# 4  Vendor (0xff)       Completed without error       00%      4990         -
# 5  Vendor (0xff)       Completed without error       00%      4978         -
# 6  Vendor (0xff)       Completed without error       00%      4965         -
# 7  Vendor (0xff)       Completed without error       00%      4953         -
# 8  Vendor (0xff)       Completed without error       00%      4789         -
# 9  Vendor (0xff)       Completed without error       00%      4776         -
#10  Vendor (0xff)       Completed without error       00%       190         -

le retour de dd me parait particulièrement lent…

est-ce que j’ai du soucis à faire ? dans ce cas y a-t-il une manip à faire (changer de SSD) ?
ou est-ce que je devrais simplement désactiver ce test ?

#2

Bon, ça, c’est comme sur linkedin, je ne comprends pas un mot sur deux à la langue, donc je n’ai aucun avis.

Par contre:

Et la disponibilité des inodes, avec df -i ?
Ton machin sous docker n’aurait pas la particularité de faire plein de petits fichiers ?

#3

merci mattotop :

krodelabestiole@micropoutre ~  sudo df -i | grep sda
/dev/sda2        6791168 1186433   5604735   18% /
/dev/sda1              0       0         0     - /boot/efi

je pense pas que l’utilisation de docker ait d’incidence sur le système de fichier.

#4

Oui pardon, je n’avais pas vu que c’était ton superviseur et que ça n’avait rien à voir avec ton probléme de vitesse.
Disons que tes sites web eux mêmes ou d’autres services auraient pu bouffer tes inodes.
Comme on y pense jamais, ça pouvait être une piste.
Mais 18% consommés seulement, c’est pas ça.

Moi c’est plutôt:

Chez moi, les débits sont triplés, et sur des ssd moins récents que les tiens.

C’est pas qu’il y a du soucis, ça peut juste être une question de réglage genre de hdparm, mais je ne sais pas trop quoi tester.
Il y a https://wiki.debian.org/SSDOptimization à gratter, et la recherche “hdparm ssd optimisation”, semble proposer d’intéressantes lectures.

#5

merci pour ton retour !

avec iotop je vois que les process qui bouffent le plus en I/O sont syncthing (normal) max à 50% mais en général beaucoup moins et surtout [jbd2/sda2-8] donc le journal de ext4. là c’est presque constamment entre 50% et 100%.
je serais tenté de le désactiver mais ça a pas l’air simple sur la partition racine (montée sur /)

krodelabestiole@micropoutre ~  sudo tune2fs -O ^has_journal /dev/sda2
tune2fs 1.44.5 (15-Dec-2018)
The has_journal feature may only be cleared when the filesystem is
unmounted or mounted read-only.

les options utilisées (seulement errors=remount-ro dans /etc/fstab) :

krodelabestiole@micropoutre ~  sudo dmesg | grep EXT4
[    3.351631] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[    3.778926] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro

là je suis en terrain inconnu, je n’y connais rien à ext4 et j’ai du mal à trouver des infos récentes, par ex. je ne sais pas si l’option noatime serait utile alors qu’apparemment c’est maintenant relatime par défaut…

#6

mais sinon le journal ext4 me parait loin d’être inutile.

mais cette consommation I/O me parait complètement excessive. c’est normal ou il s’agirait d’un bug ou d’une mauvaise config ?

#7

Salut,

Effectivement le résultat de hdparm -t est très faible pour un SSD. Le problème c’est que les causes peuvent être multiples : SSD défectueux, bug dans le firmware du SSD, mauvais réglage, etc.
Idéalement il faudrait faire des tests croisés en branchant le SSD sur une autre machine.
Dans la doc indiquée par @mattotop, il est conseillé d’activer le fstrim.timer (sauf sous buster). Est-ce le cas ? Ou que donnent les tests après un :

sudo fstrim -av
#8

salut bruno !

je suis sous buster.

krodelabestiole@micropoutre ~  sudo fstrim -v /
/: 46.3 GiB (49713205248 bytes) trimmed
#9

je sais pas si c’est à cause de cette commande mais jbd2 est entre 3% et 10% en ce moment et l’alerte zabbix a disparue…

et la vitesse de lecture depuis le buffer a quadruplé :

krodelabestiole@micropoutre ~  sudo hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads:   8522 MB in  2.00 seconds = 4270.32 MB/sec
Timing buffered disk reads: 1092 MB in  3.00 seconds = 363.82 MB/sec
#10

du coup je serais quand même tenté d’activer le “weekly trim” surtout après avoir survolé cette conversation : http://forums.debian.net/viewtopic.php?f=10&t=140417

par contre j’ai un boîtier externe (usb 3) avec 10 To de disques durs en raid5. est-ce que le daemon trim est intelligent et risque pas d’aller bidouiller quoi que ce soit de ce côté ?

#11

dans le doute j’ajoute une tâche cron :

0 3 * * 2   /usr/sbin/fstrim /

j’attends un peu avant de passer en résolu mais dans tous les cas un grand merci à tous les 2 !