_Pour le fun_ , je voulais faire un truc comme google:
J'aspire donc plein de site sur un PC, et je programme un truc pour faire
un moteur de recherche. Le tout sur mon LAN résidentiel.
J'en suis à la phase d'aspiration.
Ma démarche à été d'aspirer recursivement le resultat d'une recherche
quelconque sur google, avec l'option -H, qui crée dans le repertoire
courant tout plein de repertoire dont le nom est le nom de domaine des
sites aspirés.
Ca a mouliné une nuit entière, j'ai ensuite interrompu le prcessus.
Je me suis retrouvé avec quelques 3000 ou 4000 noms de domaines dans le
repertoire courant.
Ce que j'ai fait ensuite c'est une boucle qui se mettait à aspirer
recursivement sur ces 4000 nom de domaines, en même temps, histoire
d'exploiter au maximum les ressources... j'ai demandé à wget de se
lancer en background. Devinez quoi: au bout de quelques centaines de noms
de domaine (alors qu'il y en a 4000) on a droit à un "too many opened
files" on est limité à 8192 d'après les messages que j'ai lu. De même,
la machine n'est plus très très réactive, lancer un top prends
15minute, pour se faire jetter en disant "too many files opened"... même
remonter dans l'historique du prompt prends 5 minute...
Je suis sous Linux avec un sparc64 (Debian). C'est la première fois que
je rencontre ce problème. Est-ce normal?
Comment on "étend" ce nombre, si il y a moyen de l'étendre? Il faut
hacker le noyau?
Là, ça fait 24h que j'ai lancé un shutdown -h, il n'a tué que cron, le
MTA, ssh (c'est balot) et xfs. On attend sagement le shutdown complet, et
ça semble bien parti pour durer encore un moment.
--
Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois!
La preuve http://www.google.fr/search?q=serveur+dedie
Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
On me signale dans l'oreillette que pour GNU/Linux ça pourrait se trouver dans /proc/sys/fs/file-max ou dans /etc/sysctl.conf...
Ok. Mais avant de passer à l'acte. Est ce que cette limitation est là pour faire joli ou bien c'est "juste comme ça". Peut-être que je fais mauvais usage de mon ordinateur est que c'est pas normal de devoir étendre cette limitation? Pas d'effets secondaires à prévoir?
Bon remarque.... je vais attendre qu'il finisse son shutdown...
-- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
On me signale dans l'oreillette que pour GNU/Linux ça pourrait se trouver
dans /proc/sys/fs/file-max ou dans /etc/sysctl.conf...
Ok. Mais avant de passer à l'acte.
Est ce que cette limitation est là pour faire joli ou bien c'est "juste
comme ça".
Peut-être que je fais mauvais usage de mon ordinateur est que c'est pas
normal de devoir étendre cette limitation?
Pas d'effets secondaires à prévoir?
Bon remarque.... je vais attendre qu'il finisse son shutdown...
--
Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois!
La preuve http://www.google.fr/search?q=serveur+dedie
Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
On me signale dans l'oreillette que pour GNU/Linux ça pourrait se trouver dans /proc/sys/fs/file-max ou dans /etc/sysctl.conf...
Ok. Mais avant de passer à l'acte. Est ce que cette limitation est là pour faire joli ou bien c'est "juste comme ça". Peut-être que je fais mauvais usage de mon ordinateur est que c'est pas normal de devoir étendre cette limitation? Pas d'effets secondaires à prévoir?
Bon remarque.... je vais attendre qu'il finisse son shutdown...
-- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
Sébastien Kirche
Le 4 Apr 2005, Rakotomandimby Mihamina a formulé :
On me signale dans l'oreillette que pour GNU/Linux ça pourrait se trouver dans /proc/sys/fs/file-max ou dans /etc/sysctl.conf...
Ok. Mais avant de passer à l'acte. Est ce que cette limitation est là pour faire joli ou bien c'est "juste comme ça". Peut-être que je fais mauvais usage de mon ordinateur est que c'est pas normal de devoir étendre cette limitation? Pas d'effets secondaires à prévoir?
Je suppose que cette valeur est établie de façon «politiquement correcte» dans un cadre multi-utilisateurs. J'entends par là de façon à accorder des ressources équitablement réparties.
En effet l'augmentation du nombre de descripteurs de fichiers doit fatalement se traduire par la diminution d'une autre ressource (mémoire je suppose).
Maintenant si tu es tout seul sur ton système, Taïaut !
Bon remarque.... je vais attendre qu'il finisse son shutdown...
En passant je suis allé voir la valeur de /proc/sys/fs/file-max sur ma Sparc32 : 14872 (valeur par défaut non modifiée par moi). Ce qui est plus grand que le 8192 que tu as évoqué)
Il y a peut-être une autre limite dans le shell ?
-- Sébastien Kirche
Le 4 Apr 2005, Rakotomandimby Mihamina a formulé :
On me signale dans l'oreillette que pour GNU/Linux ça pourrait se
trouver dans /proc/sys/fs/file-max ou dans /etc/sysctl.conf...
Ok. Mais avant de passer à l'acte.
Est ce que cette limitation est là pour faire joli ou bien c'est "juste
comme ça".
Peut-être que je fais mauvais usage de mon ordinateur est que c'est pas
normal de devoir étendre cette limitation?
Pas d'effets secondaires à prévoir?
Je suppose que cette valeur est établie de façon «politiquement correcte»
dans un cadre multi-utilisateurs. J'entends par là de façon à accorder des
ressources équitablement réparties.
En effet l'augmentation du nombre de descripteurs de fichiers doit
fatalement se traduire par la diminution d'une autre ressource (mémoire je
suppose).
Maintenant si tu es tout seul sur ton système, Taïaut !
Bon remarque.... je vais attendre qu'il finisse son shutdown...
En passant je suis allé voir la valeur de /proc/sys/fs/file-max sur ma
Sparc32 : 14872 (valeur par défaut non modifiée par moi). Ce qui est plus
grand que le 8192 que tu as évoqué)
Le 4 Apr 2005, Rakotomandimby Mihamina a formulé :
On me signale dans l'oreillette que pour GNU/Linux ça pourrait se trouver dans /proc/sys/fs/file-max ou dans /etc/sysctl.conf...
Ok. Mais avant de passer à l'acte. Est ce que cette limitation est là pour faire joli ou bien c'est "juste comme ça". Peut-être que je fais mauvais usage de mon ordinateur est que c'est pas normal de devoir étendre cette limitation? Pas d'effets secondaires à prévoir?
Je suppose que cette valeur est établie de façon «politiquement correcte» dans un cadre multi-utilisateurs. J'entends par là de façon à accorder des ressources équitablement réparties.
En effet l'augmentation du nombre de descripteurs de fichiers doit fatalement se traduire par la diminution d'une autre ressource (mémoire je suppose).
Maintenant si tu es tout seul sur ton système, Taïaut !
Bon remarque.... je vais attendre qu'il finisse son shutdown...
En passant je suis allé voir la valeur de /proc/sys/fs/file-max sur ma Sparc32 : 14872 (valeur par défaut non modifiée par moi). Ce qui est plus grand que le 8192 que tu as évoqué)
Il y a peut-être une autre limite dans le shell ?
-- Sébastien Kirche
Etienne de Tocqueville
"Rakotomandimby (R12y) Mihamina" a écrit sur fr.comp.os.unix :
j'ai demandé à wget de se lancer en background. Devinez quoi: au bout de quelques centaines de noms de domaine (alors qu'il y en a 4000) on a droit à un "too many opened files"
Oh ben ça, alors ! J'aurais vraiment pas deviné ! ;-) 4000 wget simultanés, avec probablement leur shell respectif, c'est à mon avis illusoire, à moins d'avoir une bonne machine bétonnée en mémoire...
Je suis sous Linux avec un sparc64 (Debian). C'est la première fois que je rencontre ce problème. Est-ce normal?
Tout a fait normal, oui.
Comment on "étend" ce nombre, si il y a moyen de l'étendre? Il faut hacker le noyau?
D'autres ont indiqué commen étendre cette limite, mais ça ne fera que repousser le problème, ça plantera par un "fork failed" à la place !
Et puis même, la machine sera tellement sur les genoux que de toute manière plus aucun process ne tournera. C'est vrai qu'on peu gagner un peu en performance en lancant plusieurs wget simultanés (pas sur le même host, bien sur) mais les performances rediminuent au dela d'un certain nombre. Il y a un juste milieu à trouver, et avec 4000, on en est bien loin !
Là, ça fait 24h que j'ai lancé un shutdown -h, il n'a tué que cron, le MTA, ssh (c'est balot) et xfs. On attend sagement le shutdown complet, et ça semble bien parti pour durer encore un moment.
A mon avis, la machine n'est pas prete de s'arréter ;-) Peut-être dans 1 heure ? Ou dans dans 10 heures ? Ou 100 ?...
"Rakotomandimby (R12y) Mihamina" <mihamina@mail.rktmb.org> a écrit sur fr.comp.os.unix :
j'ai demandé à wget de se lancer en background. Devinez quoi: au bout
de quelques centaines de noms de domaine (alors qu'il y en a 4000) on
a droit à un "too many opened files"
Oh ben ça, alors ! J'aurais vraiment pas deviné ! ;-) 4000 wget
simultanés, avec probablement leur shell respectif, c'est à mon avis
illusoire, à moins d'avoir une bonne machine bétonnée en mémoire...
Je suis sous Linux avec un sparc64 (Debian). C'est la première fois que
je rencontre ce problème. Est-ce normal?
Tout a fait normal, oui.
Comment on "étend" ce nombre, si il y a moyen de l'étendre? Il faut
hacker le noyau?
D'autres ont indiqué commen étendre cette limite, mais ça ne fera que
repousser le problème, ça plantera par un "fork failed" à la place !
Et puis même, la machine sera tellement sur les genoux que de toute
manière plus aucun process ne tournera. C'est vrai qu'on peu gagner un
peu en performance en lancant plusieurs wget simultanés (pas sur le même
host, bien sur) mais les performances rediminuent au dela d'un certain
nombre. Il y a un juste milieu à trouver, et avec 4000, on en est bien
loin !
Là, ça fait 24h que j'ai lancé un shutdown -h, il n'a tué que cron, le
MTA, ssh (c'est balot) et xfs. On attend sagement le shutdown complet, et
ça semble bien parti pour durer encore un moment.
A mon avis, la machine n'est pas prete de s'arréter ;-) Peut-être dans 1
heure ? Ou dans dans 10 heures ? Ou 100 ?...
"Rakotomandimby (R12y) Mihamina" a écrit sur fr.comp.os.unix :
j'ai demandé à wget de se lancer en background. Devinez quoi: au bout de quelques centaines de noms de domaine (alors qu'il y en a 4000) on a droit à un "too many opened files"
Oh ben ça, alors ! J'aurais vraiment pas deviné ! ;-) 4000 wget simultanés, avec probablement leur shell respectif, c'est à mon avis illusoire, à moins d'avoir une bonne machine bétonnée en mémoire...
Je suis sous Linux avec un sparc64 (Debian). C'est la première fois que je rencontre ce problème. Est-ce normal?
Tout a fait normal, oui.
Comment on "étend" ce nombre, si il y a moyen de l'étendre? Il faut hacker le noyau?
D'autres ont indiqué commen étendre cette limite, mais ça ne fera que repousser le problème, ça plantera par un "fork failed" à la place !
Et puis même, la machine sera tellement sur les genoux que de toute manière plus aucun process ne tournera. C'est vrai qu'on peu gagner un peu en performance en lancant plusieurs wget simultanés (pas sur le même host, bien sur) mais les performances rediminuent au dela d'un certain nombre. Il y a un juste milieu à trouver, et avec 4000, on en est bien loin !
Là, ça fait 24h que j'ai lancé un shutdown -h, il n'a tué que cron, le MTA, ssh (c'est balot) et xfs. On attend sagement le shutdown complet, et ça semble bien parti pour durer encore un moment.
A mon avis, la machine n'est pas prete de s'arréter ;-) Peut-être dans 1 heure ? Ou dans dans 10 heures ? Ou 100 ?...
Sébastien Kirche
Le 4 avr 2005, Etienne de Tocqueville a dit :
D'autres ont indiqué commen étendre cette limite, mais ça ne fera que repousser le problème, ça plantera par un "fork failed" à la place !
En effet, je n'ai répondu que sur les symptômes, pas sur la cause du problème.
Pour la problématique, peut-être que Mihamina devrait jeter un oeil sur le code de httrack pour piquer des idées...
-- Sébastien Kirche
Le 4 avr 2005, Etienne de Tocqueville a dit :
D'autres ont indiqué commen étendre cette limite, mais ça ne fera que
repousser le problème, ça plantera par un "fork failed" à la place !
En effet, je n'ai répondu que sur les symptômes, pas sur la cause du problème.
Pour la problématique, peut-être que Mihamina devrait jeter un oeil sur le
code de httrack pour piquer des idées...
D'autres ont indiqué commen étendre cette limite, mais ça ne fera que repousser le problème, ça plantera par un "fork failed" à la place !
En effet, je n'ai répondu que sur les symptômes, pas sur la cause du problème.
Pour la problématique, peut-être que Mihamina devrait jeter un oeil sur le code de httrack pour piquer des idées...
-- Sébastien Kirche
Khanh-Dang
Ce que j'ai fait ensuite c'est une boucle qui se mettait à aspirer recursivement sur ces 4000 nom de domaines, en même temps, histoire d'exploiter au maximum les ressources... j'ai demandé à wget de se lancer en background.
Tu lances 4000 wget simultanément... Hmmm, je ne voudrais pas dire mais ça doit certainement bloquer au niveau de la bande passante, avant de bloquer au niveau des autres ressources.
Ici, le problème n'est pas d'essayer de pouvoir lancer 4000 wget simultanément. Le théorèmte "Mauvais problème => changer de problème" s'applique ici.
Essaye plutôt de faire dans ton script quelque chose qui gère la charge de ton système. Par exemple : SI la charge est inférieure à 5 (valeur arbitraire) ET que la bande passante n'est pas pleinement utilisée, ALORS lancer un nouveau wget, SINON attendre 10 secondes avant de recommencer ce test.
Pour la charge, c'est facilement scriptable. Pour le débit, par contre il va falloir te trouver un utilitaire (je n'en ai pas en tête), ou bien faire des calculs avec ce que te fournit la commande ifconfig.
Et aussi, pour ce genre de script qui tournent sous forte charge, évite - si possible - d'utiliser des commandes externes comme grep ou awk. En effet, souvent, les shells ont très souvent des fonctions intégrés qui permettent de se passer de telles commandes.
Ce que j'ai fait ensuite c'est une boucle qui se mettait à aspirer
recursivement sur ces 4000 nom de domaines, en même temps, histoire
d'exploiter au maximum les ressources... j'ai demandé à wget de se
lancer en background.
Tu lances 4000 wget simultanément... Hmmm, je ne voudrais pas dire mais
ça doit certainement bloquer au niveau de la bande passante, avant de
bloquer au niveau des autres ressources.
Ici, le problème n'est pas d'essayer de pouvoir lancer 4000 wget
simultanément. Le théorèmte "Mauvais problème => changer de problème"
s'applique ici.
Essaye plutôt de faire dans ton script quelque chose qui gère la charge
de ton système. Par exemple : SI la charge est inférieure à 5 (valeur
arbitraire) ET que la bande passante n'est pas pleinement utilisée,
ALORS lancer un nouveau wget, SINON attendre 10 secondes avant de
recommencer ce test.
Pour la charge, c'est facilement scriptable. Pour le débit, par contre
il va falloir te trouver un utilitaire (je n'en ai pas en tête), ou bien
faire des calculs avec ce que te fournit la commande ifconfig.
Et aussi, pour ce genre de script qui tournent sous forte charge, évite
- si possible - d'utiliser des commandes externes comme grep ou awk. En
effet, souvent, les shells ont très souvent des fonctions intégrés qui
permettent de se passer de telles commandes.
Ce que j'ai fait ensuite c'est une boucle qui se mettait à aspirer recursivement sur ces 4000 nom de domaines, en même temps, histoire d'exploiter au maximum les ressources... j'ai demandé à wget de se lancer en background.
Tu lances 4000 wget simultanément... Hmmm, je ne voudrais pas dire mais ça doit certainement bloquer au niveau de la bande passante, avant de bloquer au niveau des autres ressources.
Ici, le problème n'est pas d'essayer de pouvoir lancer 4000 wget simultanément. Le théorèmte "Mauvais problème => changer de problème" s'applique ici.
Essaye plutôt de faire dans ton script quelque chose qui gère la charge de ton système. Par exemple : SI la charge est inférieure à 5 (valeur arbitraire) ET que la bande passante n'est pas pleinement utilisée, ALORS lancer un nouveau wget, SINON attendre 10 secondes avant de recommencer ce test.
Pour la charge, c'est facilement scriptable. Pour le débit, par contre il va falloir te trouver un utilitaire (je n'en ai pas en tête), ou bien faire des calculs avec ce que te fournit la commande ifconfig.
Et aussi, pour ce genre de script qui tournent sous forte charge, évite - si possible - d'utiliser des commandes externes comme grep ou awk. En effet, souvent, les shells ont très souvent des fonctions intégrés qui permettent de se passer de telles commandes.
news
Rakotomandimby (R12y) Mihamina wrote:
bonjour, ...
Si tu as un shell en temps qu'utilisateur, tu peux faire un kill -1 qui tuera tes wget (vu que tu fais un shutdown, ca ne doit pas trop te deranger...). Le kill etant une commande shell ca devrait pas poser de probleme d'ouverture de fichier. Sinon, si tu es root, tu dois pouvoir identifier et tuer des pid en allant voir dans /proc et d'en tuer un ou deux a la main avant de faire un killall wget. Probablement que pour diminuer le nb de wget, tu peux debrancher le cable reseau qqs minutes (si y'a plus de reseau, le wget s'arrete vite...).
Rakotomandimby (R12y) Mihamina wrote:
bonjour,
...
Si tu as un shell en temps qu'utilisateur, tu peux faire un kill -1 qui
tuera tes wget (vu que tu fais un shutdown, ca ne doit pas trop te
deranger...). Le kill etant une commande shell ca devrait pas poser de
probleme d'ouverture de fichier.
Sinon, si tu es root, tu dois pouvoir identifier et tuer des pid en
allant voir dans /proc et d'en tuer un ou deux a la main avant de faire
un killall wget.
Probablement que pour diminuer le nb de wget, tu peux debrancher le
cable reseau qqs minutes (si y'a plus de reseau, le wget s'arrete vite...).
Si tu as un shell en temps qu'utilisateur, tu peux faire un kill -1 qui tuera tes wget (vu que tu fais un shutdown, ca ne doit pas trop te deranger...). Le kill etant une commande shell ca devrait pas poser de probleme d'ouverture de fichier. Sinon, si tu es root, tu dois pouvoir identifier et tuer des pid en allant voir dans /proc et d'en tuer un ou deux a la main avant de faire un killall wget. Probablement que pour diminuer le nb de wget, tu peux debrancher le cable reseau qqs minutes (si y'a plus de reseau, le wget s'arrete vite...).
