J'en fait l'experience a chaque fois qu'updatedb est lance quotidiennement :
le systeme rame affreusement (de l'ordre de 5 secondes pour ouvrir un
terminal aterm, je dirais 2 secondes pour changer de bureau avec wmaker,
etc). En fait, en passant au 2.6, je n'ai jamais eu l'impression "Wow, ca
me parait plus rapide/reactif" decrits par ceux qui voulaient nous faire
essayer le 2.6 ( ;-] ) et je me demandais si je compilais mon noyau avec
les bonnes options.
C'est un 2.6.8.1 sur un Pentium Centrino (qui se repose normalement a 600
MHz mais qui passe tres vite a 1.6 GHz des qu'il y a de la charge). Je vois
dans mon .config :
D'autres variables sont interessantes pour mon probleme ?
J'y pense, X n'est pas "renice" en -10 : sa priorite est a 0.
--
Daniel Déchelotte
http://yo.dan.free.fr/
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Tharan
* Daniel Dechelotte (09 Sep 2004 16:55:03 GMT):
J'en fait l'experience a chaque fois qu'updatedb est lance quotidiennement : le systeme rame affreusement (de l'ordre de 5 secondes pour ouvrir un terminal aterm, je dirais 2 secondes pour changer de bureau avec wmaker, etc). En fait, en passant au 2.6, je n'ai jamais eu l'impression "Wow, ca me parait plus rapide/reactif" decrits par ceux qui voulaient nous faire essayer le 2.6 ( ;-] ) et je me demandais si je compilais mon noyau avec les bonnes options.
Votre problème est que vous êtes certainement limité par les entrées-sorties et non par la puissance brute du processeur, et ça, l'ordonnanceur de tâches ne pourra pas y faire grand chose.
Un disque plus rapide et surtout plus de RAM vous sera plus utile. Peut-être que votre système passe du temps à swapper pendant l'updatedb ?
-- olive
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
* Daniel Dechelotte <maitre_yodan@fr.club-internet.invalid> (09 Sep 2004 16:55:03 GMT):
J'en fait l'experience a chaque fois qu'updatedb est lance quotidiennement :
le systeme rame affreusement (de l'ordre de 5 secondes pour ouvrir un
terminal aterm, je dirais 2 secondes pour changer de bureau avec wmaker,
etc). En fait, en passant au 2.6, je n'ai jamais eu l'impression "Wow, ca
me parait plus rapide/reactif" decrits par ceux qui voulaient nous faire
essayer le 2.6 ( ;-] ) et je me demandais si je compilais mon noyau avec
les bonnes options.
Votre problème est que vous êtes certainement limité par les
entrées-sorties et non par la puissance brute du processeur, et ça,
l'ordonnanceur de tâches ne pourra pas y faire grand chose.
Un disque plus rapide et surtout plus de RAM vous sera plus utile.
Peut-être que votre système passe du temps à swapper pendant l'updatedb ?
--
olive
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
J'en fait l'experience a chaque fois qu'updatedb est lance quotidiennement : le systeme rame affreusement (de l'ordre de 5 secondes pour ouvrir un terminal aterm, je dirais 2 secondes pour changer de bureau avec wmaker, etc). En fait, en passant au 2.6, je n'ai jamais eu l'impression "Wow, ca me parait plus rapide/reactif" decrits par ceux qui voulaient nous faire essayer le 2.6 ( ;-] ) et je me demandais si je compilais mon noyau avec les bonnes options.
Votre problème est que vous êtes certainement limité par les entrées-sorties et non par la puissance brute du processeur, et ça, l'ordonnanceur de tâches ne pourra pas y faire grand chose.
Un disque plus rapide et surtout plus de RAM vous sera plus utile. Peut-être que votre système passe du temps à swapper pendant l'updatedb ?
-- olive
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Rakotomandimby Mihamina
Olivier Tharan wrote: > Un disque plus rapide et surtout plus de RAM vous sera plus utile.
updatedb scanne le disque. AMHA, un disque plus rapide rendrait le temps d'execution du scan plus court, mais _pendant_ le scan, il sera toujours ralenti ...
Peut-être que votre système passe du temps à swapper pendant l'updatedb ?
Pour peu qu'il ait swappé _avant_, si il a des choses a recuperer dans la swap _pendant_, il trainera. Si rien n'a été swappé, je pense que ca irait plus vite. Sur mon poste de travail je n'ai pas de swap. Et les 'petites' operations sont fluides pendant un updatedb.
Note: C'est bien specifique Linux tout ca: fcolc peut-etre ? -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Olivier Tharan wrote:
> Un disque plus rapide et surtout plus de RAM vous sera plus utile.
updatedb scanne le disque. AMHA, un disque plus rapide rendrait le temps
d'execution du scan plus court, mais _pendant_ le scan, il sera toujours
ralenti ...
Peut-être que votre système passe du temps à swapper pendant l'updatedb ?
Pour peu qu'il ait swappé _avant_, si il a des choses a recuperer dans
la swap _pendant_, il trainera. Si rien n'a été swappé, je pense que ca
irait plus vite. Sur mon poste de travail je n'ai pas de swap. Et les
'petites' operations sont fluides pendant un updatedb.
Note: C'est bien specifique Linux tout ca: fcolc peut-etre ?
--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Olivier Tharan wrote: > Un disque plus rapide et surtout plus de RAM vous sera plus utile.
updatedb scanne le disque. AMHA, un disque plus rapide rendrait le temps d'execution du scan plus court, mais _pendant_ le scan, il sera toujours ralenti ...
Peut-être que votre système passe du temps à swapper pendant l'updatedb ?
Pour peu qu'il ait swappé _avant_, si il a des choses a recuperer dans la swap _pendant_, il trainera. Si rien n'a été swappé, je pense que ca irait plus vite. Sur mon poste de travail je n'ai pas de swap. Et les 'petites' operations sont fluides pendant un updatedb.
Note: C'est bien specifique Linux tout ca: fcolc peut-etre ? -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Eric Deveaud
Olivier Tharan wrote:
Un disque plus rapide et surtout plus de RAM vous sera plus utile. Peut-être que votre système passe du temps à swapper pendant l'updatedb ?
<PRIVATE JOKE> c'est sur que quand tous les disques sont chargé en ram comme chez certains, c'est beaucoup plus réactif. hein Olive ? </PRIVATE JOKE>
sinon la tenue en charge des noyaux-2.6 vs les 2.4 est tout de même claire et nette. nous avons comparé les 2 versions de noyaux et dans le cas de fortes charge 2.6 reste réactif. j'abonde dans le sens d'Olive
Eric, qui se demande si sa private joke vas passer la modération
-- Que 3 lignes pour le Guide du Macounet Pervers? C'est un peu comme les 640ko adressables du DOS, les 1024 secteurs maximum pour booter du BIOS, et les 15 IRQ du 80x86... C'est peu, pour ne pas dire autre chose. -+- ED in Guide du Macounet Pervers : Meta, contre ou contre meta ? -+-
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Olivier Tharan wrote:
Un disque plus rapide et surtout plus de RAM vous sera plus utile.
Peut-être que votre système passe du temps à swapper pendant l'updatedb ?
<PRIVATE JOKE>
c'est sur que quand tous les disques sont chargé en ram comme
chez certains, c'est beaucoup plus réactif. hein Olive ?
</PRIVATE JOKE>
sinon la tenue en charge des noyaux-2.6 vs les 2.4 est tout de même
claire et nette. nous avons comparé les 2 versions de noyaux et dans le
cas de fortes charge 2.6 reste réactif.
j'abonde dans le sens d'Olive
Eric, qui se demande si sa private joke vas passer la modération
--
Que 3 lignes pour le Guide du Macounet Pervers? C'est un peu comme les
640ko adressables du DOS, les 1024 secteurs maximum pour booter du BIOS,
et les 15 IRQ du 80x86... C'est peu, pour ne pas dire autre chose.
-+- ED in Guide du Macounet Pervers : Meta, contre ou contre meta ? -+-
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Un disque plus rapide et surtout plus de RAM vous sera plus utile. Peut-être que votre système passe du temps à swapper pendant l'updatedb ?
<PRIVATE JOKE> c'est sur que quand tous les disques sont chargé en ram comme chez certains, c'est beaucoup plus réactif. hein Olive ? </PRIVATE JOKE>
sinon la tenue en charge des noyaux-2.6 vs les 2.4 est tout de même claire et nette. nous avons comparé les 2 versions de noyaux et dans le cas de fortes charge 2.6 reste réactif. j'abonde dans le sens d'Olive
Eric, qui se demande si sa private joke vas passer la modération
-- Que 3 lignes pour le Guide du Macounet Pervers? C'est un peu comme les 640ko adressables du DOS, les 1024 secteurs maximum pour booter du BIOS, et les 15 IRQ du 80x86... C'est peu, pour ne pas dire autre chose. -+- ED in Guide du Macounet Pervers : Meta, contre ou contre meta ? -+-
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Jeremy JUST
On 09 Sep 2004 16:55:03 GMT Daniel Dechelotte wrote:
D'autres variables sont interessantes pour mon probleme ?
Comme cela t'a été dit, tes ralentissements ne doivent pas être directement dûs au noyau et à l'ordonnancement des tâches, mais plutôt aux I/O.
Sur un portable au disque un peu lent, je constate ça aussi, alors qu'une machine de bureau avec un disque plus rapide (mais un processeur plus lent) n'est pas aussi freinée par updatedb ou makewhatis.
J'y pense, X n'est pas "renice" en -10 : sa priorite est a 0.
Oui, il me semblait qu'il était d'usage de dénicer X, mais sur les distributions récentes, ce n'est plus le cas. Comme je trouve que ça améliore notablement le confort, je l'ai refait. Pour ça, j'ai changé une ligne de /etc/X11/xdm/Xservers :
:0 local /usr/X11R6/bin/X -deferglyphs 16
est devenue
:0 local /bin/nice -n -10 /usr/X11R6/bin/X -deferglyphs 16
Ça rend l'interface beaucoup plus agréable à utiliser (la souris ne « colle » plus à l'écran).
-- Jérémy JUST
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
On 09 Sep 2004 16:55:03 GMT
Daniel Dechelotte <maitre_yodan@fr.club-internet.invalid> wrote:
D'autres variables sont interessantes pour mon probleme ?
Comme cela t'a été dit, tes ralentissements ne doivent pas être
directement dûs au noyau et à l'ordonnancement des tâches, mais plutôt
aux I/O.
Sur un portable au disque un peu lent, je constate ça aussi, alors
qu'une machine de bureau avec un disque plus rapide (mais un processeur
plus lent) n'est pas aussi freinée par updatedb ou makewhatis.
J'y pense, X n'est pas "renice" en -10 : sa priorite est a 0.
Oui, il me semblait qu'il était d'usage de dénicer X, mais sur les
distributions récentes, ce n'est plus le cas. Comme je trouve que ça
améliore notablement le confort, je l'ai refait.
Pour ça, j'ai changé une ligne de /etc/X11/xdm/Xservers :
:0 local /usr/X11R6/bin/X -deferglyphs 16
est devenue
:0 local /bin/nice -n -10 /usr/X11R6/bin/X -deferglyphs 16
Ça rend l'interface beaucoup plus agréable à utiliser (la souris ne
« colle » plus à l'écran).
--
Jérémy JUST <jeremy_just@netcourrier.com>
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
On 09 Sep 2004 16:55:03 GMT Daniel Dechelotte wrote:
D'autres variables sont interessantes pour mon probleme ?
Comme cela t'a été dit, tes ralentissements ne doivent pas être directement dûs au noyau et à l'ordonnancement des tâches, mais plutôt aux I/O.
Sur un portable au disque un peu lent, je constate ça aussi, alors qu'une machine de bureau avec un disque plus rapide (mais un processeur plus lent) n'est pas aussi freinée par updatedb ou makewhatis.
J'y pense, X n'est pas "renice" en -10 : sa priorite est a 0.
Oui, il me semblait qu'il était d'usage de dénicer X, mais sur les distributions récentes, ce n'est plus le cas. Comme je trouve que ça améliore notablement le confort, je l'ai refait. Pour ça, j'ai changé une ligne de /etc/X11/xdm/Xservers :
:0 local /usr/X11R6/bin/X -deferglyphs 16
est devenue
:0 local /bin/nice -n -10 /usr/X11R6/bin/X -deferglyphs 16
Ça rend l'interface beaucoup plus agréable à utiliser (la souris ne « colle » plus à l'écran).
-- Jérémy JUST
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Daniel Dechelotte
Olivier Tharan <olive+ a écrit :
| Votre problème est que vous êtes certainement limité par les | entrées-sorties et non par la puissance brute du processeur, et ça, | l'ordonnanceur de tâches ne pourra pas y faire grand chose. | | Un disque plus rapide et surtout plus de RAM vous sera plus utile. | Peut-être que votre système passe du temps à swapper pendant l'updatedb ?
Merci pour vos reponses. Comme vous avez ete nombreux a le pressentir, c'est effectivement un probleme de swap. En lancant updatedb a la main, et avec un systeme peu charge (en terme d'utilisation memoire), je ne sens pratiquement pas le gros processus. Il se trouve qu'updatedb est la plupart du temps lance par anacron, 5 minutes apres la reprise du portable et sa mise sur le secteur. Je m'apercois qu'a ce moment, le swap est souvent utilise (je dois oublier de fermer gimp2 et autres applis utilisees a la maison) ; en tout cas c'est ce que j'ai constate ce matin, alors qu'updatedb faisait "ramper" ma machine. Ca recoupe ce que vous suggeriez : avec de nombreuses entrees/sorties, en particulier pour le swap, ca va ramer, noyau "preemptible" ou pas. Bien vu :) et bonne journee.
-- Daniel Déchelotte http://yo.dan.free.fr/
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Olivier Tharan <olive+news@usenet-fr.net> a écrit :
| Votre problème est que vous êtes certainement limité par les
| entrées-sorties et non par la puissance brute du processeur, et ça,
| l'ordonnanceur de tâches ne pourra pas y faire grand chose.
|
| Un disque plus rapide et surtout plus de RAM vous sera plus utile.
| Peut-être que votre système passe du temps à swapper pendant l'updatedb ?
Merci pour vos reponses. Comme vous avez ete nombreux a le pressentir,
c'est effectivement un probleme de swap. En lancant updatedb a la main, et
avec un systeme peu charge (en terme d'utilisation memoire), je ne sens
pratiquement pas le gros processus. Il se trouve qu'updatedb est la plupart
du temps lance par anacron, 5 minutes apres la reprise du portable et sa
mise sur le secteur. Je m'apercois qu'a ce moment, le swap est souvent
utilise (je dois oublier de fermer gimp2 et autres applis utilisees a la
maison) ; en tout cas c'est ce que j'ai constate ce matin, alors
qu'updatedb faisait "ramper" ma machine. Ca recoupe ce que vous suggeriez :
avec de nombreuses entrees/sorties, en particulier pour le swap, ca va
ramer, noyau "preemptible" ou pas. Bien vu :) et bonne journee.
--
Daniel Déchelotte
http://yo.dan.free.fr/
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
| Votre problème est que vous êtes certainement limité par les | entrées-sorties et non par la puissance brute du processeur, et ça, | l'ordonnanceur de tâches ne pourra pas y faire grand chose. | | Un disque plus rapide et surtout plus de RAM vous sera plus utile. | Peut-être que votre système passe du temps à swapper pendant l'updatedb ?
Merci pour vos reponses. Comme vous avez ete nombreux a le pressentir, c'est effectivement un probleme de swap. En lancant updatedb a la main, et avec un systeme peu charge (en terme d'utilisation memoire), je ne sens pratiquement pas le gros processus. Il se trouve qu'updatedb est la plupart du temps lance par anacron, 5 minutes apres la reprise du portable et sa mise sur le secteur. Je m'apercois qu'a ce moment, le swap est souvent utilise (je dois oublier de fermer gimp2 et autres applis utilisees a la maison) ; en tout cas c'est ce que j'ai constate ce matin, alors qu'updatedb faisait "ramper" ma machine. Ca recoupe ce que vous suggeriez : avec de nombreuses entrees/sorties, en particulier pour le swap, ca va ramer, noyau "preemptible" ou pas. Bien vu :) et bonne journee.
-- Daniel Déchelotte http://yo.dan.free.fr/
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
