nicoueron Posted August 25, 2022 #1 Posted August 25, 2022 Bonjour à tous, Je poste ici un pb que je constate depuis que j'ai la fibre - je ne m'en étais jamais rendu compte auparavant car je n'avais pas d'abonnement chez Uptobox et encore moins quand j'avais l'adsl évidement. Bref, lorsque je télécharge un fichier depuis Uptobox, le téléchargement est bridé à 25Mo/s. Pour certains vous allez me dire que bon c'est pas si mal, mais normalement je devrais être aux alentours de 100Mo/s (comme sur mon PC par exemple). C'est un constat que je fais exclusivement avec DownloadStation et les téléchargements en http, je n'ai pas le pb avec les torrent, le débit est bien à 100Mo/s. En regardant de plus près les processus, mon NAS surconsomme la CPU pour le téléchargement en cours et notamment le service lftp de DownloadStation qui monopolise tout. Je suspecte un pb de trame http qui nécessite une vérification de chaque paquet. J'aurai envie de jouer avec le MTU (dont la valeur par défaut est 1500) du NAS mais j'ai peur de faire une bêtise. Avez-vous une idée ? Pour info, le NAS est relié directement à ma Freebox Delta en gigabit avec un cable cat 7 et je me répête aucun pb avec des torrent, c'est exclusivement avec un download http (ou https). Quote
Orphée Posted August 26, 2022 #2 Posted August 26, 2022 (edited) J'ai pas la fibre chez moi, mais le NAS de backup que je stock chez ma mère a la fibre... 300Mo/s je crois. Je viens d'y lancer la DL d'une ISO Linux : C'est un HP N54L baremetal avec RP 7.1 DS3615xs. Edit : Je vais en effet plus vite avec les torrent : Cependant, il faut aussi prendre en compte la bande passante du site en émission HTTP. Peut-être n'ont-ils pas la capacité d'envoyer aussi vite que tu peux récupérer, ou bien ils brident délibérément pour garantir une qualité moyenne a tous les visiteurs... ? Edit 2 : En terme de charge CPU, en effet, le DL HTTP consomme beaucoup : Dans la mesure où c'est un double coeur, j'imagine qu'il met à 100% un des 2 coeurs. Edited August 26, 2022 by Orphée Quote
nicoueron Posted August 26, 2022 Author #3 Posted August 26, 2022 merci pour cet exercice. J'arrive de temps en temps à faire des pointe à 30-35Mo/s également. C'est donc bien une limitation de performance du N54L dans le cadre d'un download http. Le truc, c'est que si il consomme autant c'est qu'il corrige des erreurs de transmissions, je ne vois pas d'autres explications. Je suis sur que si nous avions un CPU plus performant nous nous en rendrions pas compte. Donc à ce jour ma seule piste reste donc le MTU. A tester au risque de planter l'interface réseau du NAS^^ Quote
Orphée Posted August 26, 2022 #4 Posted August 26, 2022 (edited) Alors ne serai pas si catégorique... J'ai oublié que j'ai un serveur Linux hébergé chez OVH. Il est tout à fait capable de DL à 100Mo/s (je m'en sert comme seedbox entre autre...) Et j'ai donc lancé le DL de l'ISO Linux dessus : Au final, vitesse semblable à celle observée sur Download Station avec le NAS. Je penche vraiment pour une limitation de bande passante côté serveur distant. Il faudrait trouver un serveur distant dont on est sur qu'il upload à genre 100Mo/s. Sinon c'est une limitation du protocole HTTP je sais pas... j'ai jamais creusé le sujet. Edit : En utilisant aria2c qui permet de faire du téléchargement multiple sur une URL : 92Mo/s Edit 2 : lftp serait à priori capable de faire du DL multiple : https://www.cyberciti.biz/tips/linux-unix-download-accelerator.html Quote Please note that by using download accelerator you are going to put a load on remote host. Also note that lftp may not work with sites that do not support multi-source downloads or blocks such requests at firewall level. Est-ce que Download Station utilise cette fonctionnalité, c'est peu probable. Edited August 26, 2022 by Orphée Quote
nicoueron Posted August 27, 2022 Author #5 Posted August 27, 2022 Non comme je l'ai indiqué ce n'est pas le serveur distant qui pose pb. Le download du même fichier (ou d'autres peut importe) depuis un autre client (mon pc perso par exemple) plafonne bien à 100Mo/s. C'est clairement le processus qui sature le CPU. Mais la raison est j'en suis quasiment sur est le checksum des paquets qui pour une raison qui m'échappe nécessite une correction des trames qui utilise toute la CPU et donc bloque le débit. J'ai eu un moment le même pb avec les transfert SMB (consommation CPU à 100%M et débit plafonné entre 10 et 15Mo/s) et cela venait du cable réseau RJ45 entre mon switch et le NAS qui était de mauvaise qualité semble-t-il. Pour être plus précis il avait un connecteur metallique qui devait avoir un tout petit défaut et je l'ai remplacé par un autre cable avec un connecteur en plastique et depuis RAS. Mais là pour lftp je ne pense pas que ce soit le cable mais plutot un pb de MTU ou qqchose du genre. Quote
JacquesF Posted August 27, 2022 #6 Posted August 27, 2022 Bonjour, Un paramètre qui peut être intéressant dans le man de lftp (et qui doit pouvoir se fixer dans un fichier de config) : ftp:ssl-protect-data (boolean) if true, request SSL connection for data transfers. This provides privacy and trans‐ mission error correction. Was cpu-intensive on old CPUs. Default is true. Si le téléchargement est en https (la quasi totalité des serveurs le sont), ça pourrait expliquer le délai et la charge CPU. Bons tests Jacques 1 Quote
nicoueron Posted August 30, 2022 Author #7 Posted August 30, 2022 Le 27/08/2022 à 14:09, JacquesF a dit : Bonjour, Un paramètre qui peut être intéressant dans le man de lftp (et qui doit pouvoir se fixer dans un fichier de config) : ftp:ssl-protect-data (boolean) if true, request SSL connection for data transfers. This provides privacy and trans‐ mission error correction. Was cpu-intensive on old CPUs. Default is true. Si le téléchargement est en https (la quasi totalité des serveurs le sont), ça pourrait expliquer le délai et la charge CPU. Bons tests Jacques Très bonne piste mais hélas sans succès. Juste pour préciser mon test : j’ai modifié le fichier /etc/lftp.conf puis redémarrer le service DownloadStation et relancer un nouveau téléchargement mais toujours pareil. Quote
JacquesF Posted August 30, 2022 #8 Posted August 30, 2022 Bonjour, Dommage... peut-être vérifier dans la ligne de commande (via un ps et je ne sais plus si l'option -w passe avec busybox, j'en doute) auels paramètres sont utilisés lors du téléchargement, si c'est visible. Autrement dans /proc/PIDduProgramme on peut trouver la ligne de commande. Bons tests Jacques Quote
nicoueron Posted August 31, 2022 Author #9 Posted August 31, 2022 Voici la ligne de commande qui est lancée lors d'un téléchargement https : root@NAS:~# ps -ef | grep lftp Downloa+ 14286 1 72 10:35 ? 00:00:17 /var/packages/DownloadStation/target/bin/lftp --norc -c set ssl:verify-certificate false;set syn o:task-id 1158;set syno:username niko44;set net:timeout 30;set net:max-retries 3;set http:user-agent "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/5 35 (KHTML, like Gecko) Chrome/14 Safari/535";set xfer:log false;pget -c -n 4 -O /volume1/@download/1158 "https://www79.uptobox.com/dl/BLABLABLA.iso"; J'ai l'impression que DownloadStation utilise sa propre configuration de lftp sans tenir compte du fichier /etc/lftp.conf car l'option ssl:verify-certificate false n'est pas dans le fichier de config alors que ce n'est pas la valeur par défaut. De même je ne vois pas d'autre fichier de config associé dans lequel je pourrai mettre ton flag. Quote
JacquesF Posted August 31, 2022 #10 Posted August 31, 2022 Pas évident à trouver, mais en principe les paquets (pour ce que j'en ai vu) placent leur config dans /var/package. Je tenterai ça : grep -R "ssl:verify-certificate" /var 2>/dev/null L'option -R suit les liens symboliques au cas où... Ça devrait te dire dans quel fichier se trouve cette option, et par là le modifier éventuellement. Jacques 1 Quote
nicoueron Posted September 1, 2022 Author #11 Posted September 1, 2022 J'avais déjà essayé de regarder si il y avait des fichiers de conf qui serait utiliser par lftp mais hélas aucun fichier autre que le binaire lftp ne contient ces paramètres... J'ai l'impression que c'est un binaire spécifique dédié à DownloadStation pré-compilé avec ces instructions et du coup ce n'est pas modifiable - dommage Quote
JacquesF Posted September 1, 2022 #12 Posted September 1, 2022 Dernier recours... Compiler le programme soi-même avec les options voulues en dur et remplacer (via un lien physique) le binaire fourni ??? Pas certain que le jeu en vaille la chandelle. Jacques Quote
nicoueron Posted September 1, 2022 Author #13 Posted September 1, 2022 autre idée : remplacer le binaire /var/packages/DownloadStation/target/bin/lftp par un lien symbolique qui pointe vers l'autre binaire lftp natif qui lui s'appuie sur le fichier de conf... Quote
nicoueron Posted September 1, 2022 Author #14 Posted September 1, 2022 Bon mon idée en tout cas génère en boucle de nouveau processus lftp! soit une belle boucle infinie... Quote
JacquesF Posted September 1, 2022 #15 Posted September 1, 2022 Tu peux tester en renommant le fichier dans le même répertoire, ou en faisant un lien physique au lien d'un lien symbolique (mais dans ce cas, on doit être sur la même partition). Tester avant le binaire en ligne de commande pour voir s'il ne provoque pas un plantage (architecture ou dépendances incorrectes). J. Quote
nicoueron Posted September 1, 2022 Author #16 Posted September 1, 2022 Pas possible hélas : root@NAS:/var/packages/DownloadStation/target/bin# ln -i /usr/bin/lftp lftp ln: failed to create hard link 'lftp' => '/usr/bin/lftp': Invalid cross-device link En tout cas merci pour ces pistes @JacquesF Quote
JacquesF Posted September 1, 2022 #17 Posted September 1, 2022 La réponse à la commande semble indiquer que la cible et la destination sont les mêmes fichiers. La commande 'ls -li' indique dans le premier champ le n° d'inode associé au fichier, si ce sont les mêmes sur les 2 c'est effectivement un lien physique. Dans ce cas, renommer les 2 par sécurité et copie le nouveau programme aux deux emplacements sous le nom d'origine permettra au moins de faire un test, ceci sous réserve que le programme fonctionne effectivement dans l'environnement du NAS. Il faudra peut-être regarder les droits étendus qui peuvent être associés au fichier, mais je ne suis pas certain que ce soit utilisé pour les binaires. Ça l'est pour les dossiers partagés en tout cas. Jacques Quote
nicoueron Posted September 1, 2022 Author #18 Posted September 1, 2022 Je ne suis pas sur d'avoir compris. l'inode est différent c'est sur. Je pense qu'ici c'est comme tu l'indiquais : ils ne sont pas sur la même partition. Tant pis ça restera comme ça! Quote
JacquesF Posted September 2, 2022 #19 Posted September 2, 2022 Les différences entre les liens physiques et symboliques : [jacques@jacques test]$ ls -li total 0 132252199 lrwxrwxrwx 1 jacques jacques 4 sept. 2 10:41 titi -> toto 132252192 -rw-r--r-- 2 jacques jacques 0 sept. 2 10:41 toto 132252192 -rw-r--r-- 2 jacques jacques 0 sept. 2 10:41 tutu Les 3 noms pointent vers le même fichier (vide) toto. titi est un lien symbolique (visible par le "l" qui précède les droits (en principe toujours 777, soit rwxrwxrwx, car ils sont vérifiés sur le fichier cible). tutu est un lien physique vers toto car le numéro d'inode 132252192 est identique pour les deux fichiers. La taille du fichier est la même (0 octet) dans ce cas. Dans le cas d'un lien symbolique, la taille du lien correspond en fait à la longueur de la chaîne de caractères qui contient le chemin vers le fichier (ici le lien est relatif, donc toto faisant 4 caractères, le lien en fait 4). Un lien physique ne peut être créé que dans un même système de fichiers (en fait chaque nom de fichier pointe vers le même emplacement indiqué par l'inode). Un lien symbolique pointe où l'on veut, même vers des montages réseau. La différence de fonctionnement est que pour un lien symbolique, si le fichier cible disparaît, le lien est mort, alors que pour un lien physique le fichier continue d'exister tant qu'il existe un nom (une référence) qui pointe vers lui (le nombre de lien est indiqué dans le 3ème champ dans mon exemple, ici 2). Dans ton cas, il faut vérifier que le programme lftp est bien soit la cible d'un lien symbolique (facilement visible avec "ls -l") ou celle d'un lien physique (infos à afficher pour chaque instance du programme), dans ce cas soit le n° d'inode est à vérifier (par "ls -li") soit le nombre de liens indiqué dans le 2ème ou 3ème champ de la commande "ls" selon qu'on utilise les options "-l" ou "-li". Jacques Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.