J'ai voulu transférer un gros fichier tar (3.5 Go) entre deux serveurs
Linux, mais j'ai rencontré des problèmes : au milieu du transfert le
comptage du nombre d'octets transférés s'est retrouvé négatif (pb de
variable qui ne supporte pas les grands nombres ?).
Et un peu plus tard, ça a carrément planté :
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/x-tar]
Lance un top sur les deux machines en même temps, histoire de voir si c'est Apache qui prend trop de processeur.
Apache est largement en tête lors du transfert.
S'il utilise beaucoup de processeur pour un simple transfert de fichier, c'est soit une erreur de configuration, soit un bug.
La monopolisation du processeur vient de l'option SSL.
Lorsque je passe par SSL, le %CPU oscille entre 60.0 et 70.0. Alors qu'en ne passant pas par SSL, le %CPU ne dépasse pas le 7.0.
Et du coup, le taux de transfert remonte au niveau de celui par FTP.
-- David LE BOURGEOIS E-mail : david.lebourgeois (at) free.fr Jabber : david.lebourgeois (at) jabber.fr PGP : http://david.lebourgeois.free.fr/pgp/pubkey.asc
O.L.
David LE BOURGEOIS a présenté l'énoncé suivant :
Je n'ai jamais rencontré cette erreur avec wget. Mais quand il s'agit de télécharger un fichier dont la taille est de l'ordre du Go, je me tourne plutôt vers curl.
OK merci, je note, et j'essaierai ça la prochaine fois :) (man curl ?)
Je n'ai jamais rencontré cette erreur avec wget. Mais quand il s'agit de
télécharger un fichier dont la taille est de l'ordre du Go, je me tourne
plutôt vers curl.
OK merci, je note, et j'essaierai ça la prochaine fois :)
(man curl ?)
Je n'ai jamais rencontré cette erreur avec wget. Mais quand il s'agit de télécharger un fichier dont la taille est de l'ordre du Go, je me tourne plutôt vers curl.
OK merci, je note, et j'essaierai ça la prochaine fois :) (man curl ?)
