Montage SSHFS devenu lent.

[Mackguil]

Je transfère sur un serveur distant (vps), des fichiers sur un volume veracrypt via rsync dans un tunnel ssh dont je monte le système de fichier via sshfs, jusqu'à là rien de compliqué.

Par contre depuis quelques jours c'est devenu leeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeent, 2MB/s maximum.

Rien n'a changé depuis des années niveau configuration, matos ou vitesse de connexion, une idée/piste du keskispasss ?

[solar10]

Windows/linux?
Y a eu un update de quelque chose?

[Unix-Linux]

+1 solar ;-)
Quand cela m'arrive avec un VPS distant, update && upgrade && autoremove && reboot

[Mackguil]

Windows/linux?
Y a eu un update de quelque chose?

Linux, mais j'ai essayé avec un restore de backup datant de l'année dernière, le problème reste entier, les updates n'y sont donc pour rien.

Ajouté après : 2 minutes 34 secondes:

+1 solar ;-)
Quand cela m'arrive avec un VPS distant, update && upgrade && autoremove && reboot

Le système à jour, reboot déjà effectué,autoremove et autoclean aussi.

[Unix-Linux]

N'est-ce pas purement un problème de réseau ? Encombrement/saturation ? Que ce soit de "ton coté" ou bien du coté du VPS ?

[Mackguil]

N'est-ce pas purement un problème de réseau ? Encombrement/saturation ? Que ce soit de "ton coté" ou bien du coté du VPS ?

Il dure depuis des jours alors, par contre si j'utilise nfs sans passer par ssh, vitesse normal de transfert.

[solar10]

+1 solar ;-)
Quand cela m'arrive avec un VPS distant, update && upgrade && autoremove && reboot

La question était de pouvoir déterminer si un update était responsable de cette différence de performance. Pas de savoir si le serveur est "up-to-date".
Apparemment, y a un truc sur la ligne qui foire entre les machines.
Des CPL peut-être ? :smurf:

[Mackguil]

Des CPL peut-être ? :smurf:

Mouhahahahahaha.

[Unix-Linux]

+1 solar ;-)
Quand cela m'arrive avec un VPS distant, update && upgrade && autoremove && reboot

La question était de pouvoir déterminer si un update était responsable de cette différence de performance. Pas de savoir si le serveur est "up-to-date".
Apparemment, y a un truc sur la ligne qui foire entre les machines.
Des CPL peut-être ? :smurf:

J'avais bien compris. Donc lorsque tu as un bug avec une mise à jour, tu fais une autre autre mise à jour non ? A moins de remettre l'ancien paquet à la place.

[Rodrigue]

cpl 1200+ / 2400+ vont rapide :)
lol
tu marres?

[Mackguil]

cpl 1200+ / 2400+ vont rapide :)
lol
tu marres?

Ce n'est pas le sujet.

[Rodrigue]

ok mackguil

[mistertix]

roro sort ses cpl 1200+ et 2400+ :

[Mackguil]

roro sort ses cpl 1200+ et 2400+ :

Ouaip, dans le genre.

[Mackguil]

J'ai essayé la copie via nfs, ftp, dans et en dehors du container veracrypt sans passer via ssh, vitesse normal.

Si j'utilise ssh pour crypter la connexion, ça merdouille de nouveau.

[solar10]

Y aurait pas comme un serveur tiers de validation de ta clef de cryptage qui fait ramer?

[Unix-Linux]

Le plus simple : vider ton ~/.ssh/known_hosts et te reconnecter, de cette façon tu auras une nouvelle clef

[Mackguil]

Le plus simple : vider ton ~/.ssh/known_hosts et te reconnecter, de cette façon tu auras une nouvelle clef

Déjà essayé, j'avais même réactiver la connexion via user/password pour tester, idem.

Ajouté après : 1 minute 38 secondes:

Y aurait pas comme un serveur tiers de validation de ta clef de cryptage qui fait ramer?

Euh SSH, c'est du client <==> serveur direct, comprend pas ta question.

[Unix-Linux]

Je pense comprendre ce que Solar veut dire avec le serveur tiers de validation.
Comme tu dis, Mackguil, SSH = client>--<serveur directement, s'il y en a un troisième entre les deux pour moi ça devient un MITM (Man-in-the-Middle Attack) et la ça sent le moisi

[sohka]

Bonjour,

J’essaierais de changer le port des deux instances SSH. Peut être que l’hébergeur le bride ?

Un peu tiré par les cheveux, mais est ce que le CPU d’un des deux serveurs a été changé ? Genre il disposait des instructions AES et elles ont été retirées ?

code : Tout sélectionner

grep aes /proc/cpuinfo