Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Pb avec wget et gros fichiers

24 réponses
Avatar
O.L.
Bonjour,

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]

[ <=> ] -937,947,136 9.73M/s

wget: retr.c:292: calc_rate: Assertion `bytes >= 0' failed.
Aborted


Une idée ?

Merci d'avance,
Olivier

--
Olivier Ligny
www.virgal.net (Monde persistant)

10 réponses

1 2 3
Avatar
Fabien LE LEZ
On 15 Jul 2007 09:50:02 GMT, David LE BOURGEOIS :

En effet, j'ai eu une ou deux fois le problème des 2 Go avec wget.


Avec quelle version ?

Et puis, on peut créer des données supplémentaires de réparation avec
par2, pour corriger d'éventuelles erreurs durant le transfert.


Attention, je crois me souvenir avoir eu des soucis avec par2 sur des
fichiers de plus de 2 Go.

Enfin, préférer le protocole FTP au HTTP pour les fichiers de cette
taille est de bon usage.


Pourquoi ?
Y a-t-il encore, en 2007, une raison valable à cette règle ?

Avatar
David LE BOURGEOIS
On 15 Jul 2007 09:50:02 GMT, David LE BOURGEOIS :

En effet, j'ai eu une ou deux fois le problème des 2 Go avec wget.


Avec quelle version ?


GNU Wget 1.9.1

Je devais sûrement être dans le cas annoncé sur
http://debian.fr/CD/http-ftp :
« [...]
Veuillez utiliser à la place un outil qui permet la reprise des
téléchargements interrompus. Sous Unix, vous pouvez utiliser « wget -c
lien » ou « curl -C - lien ». Veuillez noter que certaines versions de
wget ne gère pas le téléchargement d'images de la taille d'un dévédérom.
[...] ».

Et puis, on peut créer des données supplémentaires de réparation avec
par2, pour corriger d'éventuelles erreurs durant le transfert.


Attention, je crois me souvenir avoir eu des soucis avec par2 sur des
fichiers de plus de 2 Go.


Oui, c'est pour ça aussi que je conseille entre autres de découper les
gros fichiers.

Enfin, préférer le protocole FTP au HTTP pour les fichiers de cette
taille est de bon usage.


Pourquoi ?
Y a-t-il encore, en 2007, une raison valable à cette règle ?


Je viens de faire le test de téléchargement entre un serveur FTP
(proftpd 1.2.9) et un serveur Web (apache 2.0.51), installés sur la même
machine.
Le fichier de test est l'iso du premier CD de la Debian Sarge.
Le transfert avec wget par FTP a mis 00:01:16 et celui par HTTP
00:01:51, soit un écart de 00:00:35.

Lorsque que j'ai le choix entre un lien HTTP et un lien FTP, je choisis
toujours celui en FTP. Pour quelle raison devrai-je, aujourd'hui plutôt
qu'hier, privilégier HTTP au lieu de FTP pour le transfert de fichier ?

--
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


Avatar
David LE BOURGEOIS
Je viens de faire le test de téléchargement entre un serveur FTP
(proftpd 1.2.9) et un serveur Web (apache 2.0.51), installés sur la même
machine.
Le fichier de test est l'iso du premier CD de la Debian Sarge.
Le transfert avec wget par FTP a mis 00:01:16 et celui par HTTP
00:01:51, soit un écart de 00:00:35.


Oups, j'oubliais la question.

D'où vient cet écart ?


--
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

Avatar
Fabien LE LEZ
On 15 Jul 2007 14:35:04 GMT, David LE BOURGEOIS :

Le transfert avec wget par FTP a mis 00:01:16 et celui par HTTP
00:01:51, soit un écart de 00:00:35.


Oups, j'oubliais la question.

D'où vient cet écart ?


C'est justement ce que j'allais te demander.
Lance un top sur les deux machines en même temps, histoire de voir si
c'est Apache qui prend trop de processeur.

Si Apache ne se mêle pas de réencoder les données transmises,
l'overhead d'HTTP est négligeable, donc le nombre d'octets transmis
est quasiment le même.


Avatar
Fabien LE LEZ
On 15 Jul 2007 14:05:01 GMT, David LE BOURGEOIS :

Pour quelle raison devrai-je, aujourd'hui plutôt
qu'hier, privilégier HTTP au lieu de FTP pour le transfert de fichier ?


Plus exactement, il y a quelques années, HTTP ne permettait pas de
continuer un téléchargement interrompu, donc ne convenait guère pour
les gros fichiers.

Avatar
Nicolas George
David LE BOURGEOIS wrote in message
<469a298d$0$7609$:
Je viens de faire le test de téléchargement entre un serveur FTP
(proftpd 1.2.9) et un serveur Web (apache 2.0.51), installés sur la même
machine.
Le fichier de test est l'iso du premier CD de la Debian Sarge.
Le transfert avec wget par FTP a mis 00:01:16 et celui par HTTP
00:01:51, soit un écart de 00:00:35.


Ma boule de cristal me dit que tu as 1 Go de mémoire, et que tu as fait le
test HTTP en premier.

Avatar
David LE BOURGEOIS
On 15 Jul 2007 14:05:01 GMT, David LE BOURGEOIS :

Pour quelle raison devrai-je, aujourd'hui plutôt
qu'hier, privilégier HTTP au lieu de FTP pour le transfert de fichier ?


Plus exactement, il y a quelques années, HTTP ne permettait pas de
continuer un téléchargement interrompu, donc ne convenait guère pour
les gros fichiers.


Je comprends mieux maintenant le pourquoi du « encore en 2007 »,
dans ton message précédent.

Merci pour la précision.


--
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


Avatar
David LE BOURGEOIS
On 15 Jul 2007 14:35:04 GMT, David LE BOURGEOIS :

Le transfert avec wget par FTP a mis 00:01:16 et celui par HTTP
00:01:51, soit un écart de 00:00:35.


Oups, j'oubliais la question.

D'où vient cet écart ?


C'est justement ce que j'allais te demander.
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. Et proftpd l'est
beaucoup moins.

C'est donc Apache qui, ne fournissant pas assez rapidement les données,
est responsable de la chute du taux de transfert.

Si Apache ne se mêle pas de réencoder les données transmises,
l'overhead d'HTTP est négligeable, donc le nombre d'octets transmis
est quasiment le même.


Oui, c'est pour ça que la différence de temps me surprenait.


--
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



Avatar
David LE BOURGEOIS
David LE BOURGEOIS wrote in message
<469a298d$0$7609$:
Je viens de faire le test de téléchargement entre un serveur FTP
(proftpd 1.2.9) et un serveur Web (apache 2.0.51), installés sur la même
machine.
Le fichier de test est l'iso du premier CD de la Debian Sarge.
Le transfert avec wget par FTP a mis 00:01:16 et celui par HTTP
00:01:51, soit un écart de 00:00:35.


Ma boule de cristal me dit que tu as 1 Go de mémoire, et que tu as fait le
test HTTP en premier.


Nan, j'ai pensé à la mise en cache.
J'ai fait 4 tests et dans un ordre privilégiant HTTP : FTP, HTTP, FTP
puis HTTP. Et les résultats donnés correspondent aux 2 derniers.

De toute façon, je n'ai que 128 Mo et qui sont déjà bien occupés :

$ free
total used free shared buffers cached
Mem: 127068 96624 30444 0 15616 34544
-/+ buffers/cache: 46464 80604
Swap: 500432 114548 385884



--
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


Avatar
Sébastien Monbrun aka TiChou
Dans le message <news:469a4c41$0$27190$,
*David LE BOURGEOIS* tapota sur f.c.o.l.configuration :

De toute façon, je n'ai que 128 Mo et qui sont déjà bien occupés :


Bof. ;-) Pas loin des deux tiers de la mémoire vive sont disponibles.

$ free
total used free shared buffers cached
-/+ buffers/cache: 46464 80604


--
Sébastien Monbrun aka TiChou

1 2 3