Le Mon, 6 Dec 2021 17:10:00 -0000 (UTC),
Marc SCHAEFER <
schaefer@alphanet.ch> a écrit :
Christophe PEREZ <chris@novazur.fr> wrote:
6 Go/10 min == 10 MByte/s.
Et ?
Ça, c'est en temps normal.
C'est déjà assez lent, en fait. Cela peut être lié au temps de
compression ou de collecte de tas de petits fichiers.
Oui, voilà, c'est lié à la lecture, et à tout le processus de backup
qui n'est pas juste une copie de fichier, compression etc...
Je donnais la valeur juste pour que l'on soit bien conscient que je ne
parle pas d'un léger ralentissement mais de quelque chose tout à fait
hors du commun.
Oui, avec débit indiqué par hdparm on s'attendra à un backup en 2
minutes.
On reste quand même dans le même ordre de grandeur, on ne passe pas de
quelques minutes à 13 heures.
Maintenant, l'écriture est peut-être bien plus lente que la lecture
testée par hdparm.
L'écriture ne se faisant pas sur la même machine surtout. Et c'est là
qu'intervient le réseau. Je pensais l'avoir sous-entendu, mais je me
rends compte que ce n'était pas forcément suffisamment explicite.
Même une connexion ssh prend du temps à s'effectuer.
Ceci fait penser à un problème de DNS.
A priori non, j'ai mon serveur DNS, rien n'a changé, le poste est connu
Les résultats sont identiques avec l'adresse IP.
des processus étranges qui tournent (top, htop) et prennent du CPU ou
de la mémoire?
Non, rien de rien justement.
Le système swappe-t-il activement (colonnes si et so de `vmstat 5`,
laisser tourner quelques minutes, la 1ère ligne est une moyenne).
Non, ce n'est pas ça non plus. Tous ces tests sont faits après reboot,
sans rien qui tourne hormis les services "normaux" et sddm.
Aucun outil ne montre le moindre élément suspect.
vmstat 5, si et so = 0.
Des erreurs dans `sudo dmesg | tail' ?
Rien ne me saute aux yeux.
Je me demande si en fait tout n'est pas qu'une question de problème de
réseau, que j'aurais à tort écarté trop tôt je ne sais plus pour quelle
raison. Vu qu'en plus le /home est en NFS, le réseau y est crucial.
une simple connexion ssh peut prendre 3 ou 13sec... (mais 10sec est le
cas général)
$ time ssh 192.168.5.7 echo
real 0m10,577s
user 0m0,000s
sys 0m0,009s
$ time ssh 192.168.5.7 echo
real 0m3,756s
user 0m0,005s
sys 0m0,005s
$ time ssh 192.168.5.7 echo
real 0m13,965s
user 0m0,009s
sys 0m0,000s
Pourtant, ethtool ne me semble pas montrer de défaut
$ ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Port: MII
PHYAD: 1
Transceiver: internal
netlink error: Operation not permitted
Link detected: yes
Mais quand je teste avec :
$ time scp ~/tmp/test poste_sans_probleme:/dev/null
test 100%
500MB 112.0MB/s 00:04
real 0m4,648s
user 0m0,864s
sys 0m0,745s
$ time scp ~/tmp/test 192.168.5.7:/dev/null
test 100%
500MB 24.9MB/s 00:20
real 0m27,867s
user 0m0,952s
sys 0m0,341s
Défaillance de la carte réseau intégrée ?
Je n'ai jamais rencontré ce type de défaut. Pour moi ça a toujours été
on/off. Ça fonctionne, ou c'est HS.
Câble réseau ? Possible, il est long, et pas simple à remplacer pour un
test. J'imagine qu'il n'y a pas d'autre moyen que de le remplacer pour
tester.
Je déplacerai la machine dès que je pourrai, pour tester sur un autre
câble.
En fait, je n'ai jamais eu de défaut de ce genre, encore moins lié à un
câble... Je pensais que c'était là aussi assez binaire, soit c'est bon,
soit c'est HS, même si je comprends bien que ça puisse être dégradé.