[Linux] Serveur qui gèle si on y copie un fichier trop grand ?

[Christophe Courtois]

Le 21/08/2018 à 17:31, Jean-Marc Libs a écrit :
> On Mon, Aug 20, 2018 at 10:36 PM Christophe Courtois
> <christophe@::1> wrote:
>     Le 20/08/2018 à 19:52, Jean-Marc Libs a écrit :
>     > Transférer le même fichier via sftp fonctionne sans souci
>     > Et pendant que j'y étais, j'ai testé via rsync sans souci:
>     > Mais un test de confirmation avec scp a bien replanté le serveur. Mais
>     > pas à 256Mo, à 168Mo cette fois-ci.
>     Bizarre, ton histoire.
> N'est-ce pas ?
>     Le débit est-il équivalent dans les 3 cas ? (jusqu'à la perte de
>     connexion en tout cas)
> À peu près:
> sftp: 9.2MB/s ou 11.6MB/s
> rsync n'a rien affiché
> scp d'un fichier complet:
> 20180818_all-databases.sql                          100%  648MB 
> 12.0MB/s   00:54

>     > Le but, évidemment, c’est pas de transmettre le fichier en question.
>     > C'est de trouver comment avoir un serveur qui se fige pas suite à des
>     > manips anodines qui n'ont rien à voir :-(
>     À tout hasard :
>      - tester avec scp -v
>      - ou scp -C (une histoire de compression ?)
>      - 256 Mo, c'est beaucoup par rapport à la mémoire du serveur cible et à
>     ses IO ? je pense à un cache qui sature (et que scp traiterait de
>     manière plus agressive ?). Il se passe quoi si tu réduis la bande
>     passante avec scp -l ?
>       - quand ça fige, c
>       - en parallèle, que disent (par exemple ) iftop, vmstat, free -m ?
>       - tu as laissé combien de temps à scp avant d'abandonner le
>     transfert ?
> J'ai re-gelé avec iftop et htop dans des fenêtre séparées.
> Alors déjà, la taille du fichier à transférer avant gel varie. j'ai pu
> passer 648MB puis le même a gelé à 228MB juste après.

Ce gel ça me rappelle mon portable lors d'un "swap storm" (sans doute
pas le cas ici ou alors tu es tombé sur un truc vraiment délirant).

> Pour résumer htop, rien ne saturait (qu'on peut pas copier/coller????)
> On the server, htop shows nothing interesting:
> * No usage of much memory
> * Load average 0.42
> * sshd 50% CPU
...
> iftop, je connaissais pas, mais voila:
> On the server, iftop gives:
...
> Je sais pas trop ce qui est étrange ou intéressant là-dedans

Rien que je trouve très surprenant.

C'est surtout en terme de "qu'est-ce qui se passe juste avant" que ce
serait intéressant, du genre le cache disque qui grimpe, grimpe... avant
que la machine doivent swapper ou vider son cache. Pas facile à suivre,
surtout si tout gèle.

J'aurais dû plutôt conseiller "sar 1", "vmstat 1", "iostat 1" (paquets
sysstat et procps) pour suivre seconde par seconde ce qui se passe.

> Bon, à moins que quelqu'un aie une idée prometteuse et comme finalement,
> ça correspond pas à un usage prévu de serveur, les scp externes, je vais
> arrêter les reboots incessants pour boucler la partie fonctionnelle et
> espérer qu'une mise à jour future corrige ça. C'est pas un serveur
> vraiment critique en terme de disponibilité (c'est pour la mise en
> évidence de bugs).

Justement, tu en as un beau, là  :-D

Il y a peut-être quelque chose dans un des /var/log/kern.log.* ?



-- 
Christophe Courtois