Matériel: PC fixe
Version de YunoHost: 4.1.4.3
J’ai accès à mon serveur : complet
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non
Bonsoir,
Depuis que j’ai dû le redémarrer suite à une panne de courant, mon serveur est lent à répondre. Sur la console ssh, il arrive régulièrement qu’il s’écoule 15 secondes entre la frappe d’une touche et sa prise en compte, de même que lors du chargement de certains services, la connexion prend souvent entre 10 et 15 secondes. Cela rend bien évidemment le monitoring impossible, que ce soit via netdata ou htop.
Je tente un ping pour avoir des infos supplémentaires. Et là, surprise: j’ai juste le message “no route to host”, alors qu’il est bel et bien accessible. Je ne peux pas non plus pinger depuis le serveur, qui me donne une soi-disant erreur temporaire de dns, alors qu’il est pourtant capable de’effectuer des requêtes vers des destinations externes.
J’ai un peu de mal à cerner le lien de cause à effet, mais avant la coupure, ce n’était pas si lent.
top - 12:09:17 up 3 days, 16:26, 2 users, load average: 0.08, 0.50, 1.35
Tasks: 344 total, 1 running, 343 sleeping, 0 stopped, 0 zombie
%Cpu(s): 9.1 us, 7.8 sy, 0.0 ni, 82.7 id, 0.2 wa, 0.0 hi, 0.2 si, 0.0 st
MiB Mem : 6969.4 total, 374.1 free, 4431.1 used, 2164.2 buff/cache
MiB Swap: 1488.0 total, 1.0 free, 1487.0 used. 2010.3 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24035 netdata 20 0 510276 62256 9068 S 5.3 0.9 220:48.76 python
14128 root 20 0 0 0 0 I 4.0 0.0 5:10.06 kworker/0:2-events
4534 root 20 0 0 0 0 I 3.3 0.0 0:01.80 kworker/1:1-events
9565 postgres 20 0 217864 17364 13528 S 3.3 0.2 66:35.31 postgres
24029 netdata 20 0 19744 9812 2876 S 3.3 0.1 157:43.75 apps.plugin
23909 netdata 20 0 408692 206692 0 S 2.3 2.9 112:11.77 netdata
1753 mobiliz+ 20 0 2169032 68320 5216 S 1.7 1.0 69:16.02 beam.smp
417 mongodb 20 0 1523984 42016 5804 S 1.3 0.6 62:04.97 mongod
876 mysql 20 0 1587972 158232 3384 S 1.0 2.2 54:13.82 mysqld
7540 matrix-+ 20 0 1308260 111216 9028 S 1.0 1.6 13:35.09 python
499 root 20 0 1230728 29668 7316 S 0.7 0.4 30:35.77 fail2ban-server
10243 lufi 20 0 86164 35140 5644 S 0.7 0.5 2:55.10 /var/www/lufi/s
19588 postgres 20 0 216192 16596 14568 S 0.7 0.2 0:04.79 postgres
24027 netdata 20 0 724088 16080 1668 S 0.7 0.2 28:47.40 go.d.plugin
9 root 20 0 0 0 0 S 0.3 0.0 3:24.60 ksoftirqd/0
10 root 20 0 0 0 0 I 0.3 0.0 13:56.68 rcu_sched
17 root 20 0 0 0 0 S 0.3 0.0 3:23.21 ksoftirqd/1
407 root 20 0 8084 4064 1532 S 0.3 0.1 0:37.78 haveged
443 diaspora 20 0 647972 215676 12144 S 0.3 3.0 12:49.03 ruby
475 debian-+ 20 0 182308 5632 4516 S 0.3 0.1 6:03.16 transmission-da
root@stemy:~# ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
enp4s0 UP 192.168.0.5/24 2a02:2788:808:444:21a:4dff:fe5a:2e1c/64 fe80::21a:4dff:fe5a:2e1c/64
tun0 UNKNOWN 80.67.181.213/25 2001:913:1fff:ffff::b:d130/64 fe80::c274:4a6:e414:ba40/64
Maintenant, il arrive à résoudre les noms de domaine.
Pour l’électricité statique, tu es sûr que ça peut être ça l’origine du problème? Est-ce que ce genre de problème peut toucher également les PC desktop ? Je préfère être sûr car j’aimerais éviter un maximum de l’éteindre.
Que veux tu dire par maintenant ?
Est-ce que “maintenant” c’est toujours lent ?
Typiquement si tu branches en USB un appareil chargé electrostatiquement (exemple un gps), ça peut transférer les charges sur l’ordi et créer des ralentissements incroyables.
Je n’y croyais pas avant de le constater une fois sur une machine de bureau justement.
Après, je dis que ça peut être ça, mais je ne dis pas que c’est le plus probable. Un problème de ressource est aussi possible (un disque dur qui devient lent, un manque de ram pour une raison x ou y…). Là ton interface tun0 n’est pa smarquée UP, du coup je me pose des question, ça vient peut être de ton vpn ? Tu es connecté en local via ssh ou à distance à travers ton vpn ?
Visiblement tu as assez de ram. Tu peux éventuellement tester ton disque (faut chercher sur le net les commandes dd qui vont bien pour tester le débit de ton disque).
Tu peux aussi tenter d’éteindre temporairement des services si tu soupçonnes que l’un d’eux est reponsable.
J’ai eu un host que n’a pas un route bon, ma il peut connecter tres lent par IPv6 local.
Sont les results de ip route et ip -6 route compatible avec des results de ip addr? Et, comme @ljf suggeste, ping un host externe ou votre gateway/router?
Haha, see!? My French is so bad that my answer is understood as an question
What I intended to say: I have had similar symptoms, where networking was very slow. In my case it turned out that a default route was missing; one way or another, IPv6 was even then able to make a connection (but very slow).
So, @stemy2, how does routing on your YNH look? Does the output of ip route and ip -6 route match with the IP ranges of ip addr ? Does ping to the router or an external host work, or is the network not reachable?
Sorry for not being able to express myself clearly in French!
I think it’s not linked to ipv6, i have the same problem if i connect to ssh with ipv4.
root@stemy:~# ip route
0.0.0.0/1 via 80.67.181.129 dev tun0
default via 192.168.0.1 dev enp4s0
80.67.181.11 via 192.168.0.1 dev enp4s0
80.67.181.128/25 dev tun0 proto kernel scope link src 80.67.181.213
128.0.0.0/1 via 80.67.181.129 dev tun0
192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.5
root@stemy:~# ip -6 route
::1 dev lo proto kernel metric 256 pref medium
2001:913:1000::11 via fe80::6eb0:ceff:fe31:5015 dev enp4s0 metric 1 pref medium
2001:913:1000::11 via fe80::6eb0:ceff:fe31:5015 dev enp4s0 metric 1024 pref medium
2001:913:1fff:ffff::/64 dev tun0 proto kernel metric 256 pref medium
2a02:2788:808:444::/64 dev enp4s0 proto kernel metric 256 expires 1188769sec pref medium
2000::/3 dev tun0 metric 1024 pref medium
fe80::/64 dev enp4s0 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
default via fe80::6eb0:ceff:fe31:5015 dev enp4s0 proto ra metric 1024 expires 1791sec hoplimit 64 pref medium
Have you heard of SMR? Many disks nowadays are based on SMR technology, which does not lend itself very well for many tasks that oldfashioned HDD already were bad at.
It could be that your disk is SMR. At first the performance is good, but it will become slow after a while.
