Depuis quelques temps (1 mois?), nautilus est tr=E8s lent =E0 explorer
(=E0 afficher) les r=E9pertoires de ma machine (Dell Precision 360,
debian etch).
Je constate cette lenteur notamment sur mon homedir (montage nfs)
qui contient d'assez nombreux r=E9pertoires et fichiers :
$ ls -al | wc -l
500
M=EAme lenteur pour les montages smb et les r=E9pertoires locaux.
Par exemple, il me faut attendre de 8 =E0 10 secondes pour que nautilus
commence =E0 afficher mon homedir. Pendant ce temps, 100% du cpu est
utilis=E9 (roue dent=E9e qui tourne, page blanche). D=E8s que l'affichage
commence, toutes les lignes s'affichent presque imm=E9diatement.
J'ai l'impression que la vitesse d'affichage d=E9pend directement
du nombre de lignes et de colonnes =E0 afficher.
Ce qui est remarquable, c'est que sur ces r=E9pertoires (et notamment
mon homedir) :
- l'affichage est imm=E9diat avec un 'ls -al'
- l'affichage est imm=E9diat avec konqueror
- l'affichage est imm=E9diat sur d'autres PC =E9quip=E9s de debian etch.
- un 'du -ks .[a-zA-Z0-9]* *' met moins de 10 secondes et utilise
assez peu le cpu sur le homedir.
J'ai test=E9 plusieurs version de kernel (de 2.6.15-1-686-smp =E0
2.6.18-2-686). Le comportement est le m=EAme.
On dirait que c'est la gestion en m=E9moire vive des entr=E9es qui
lui pose probl=E8me. Si je cache toutes les colonnes en ne laissant
visible que le nom, j'ai une am=E9lioration sensible. Apr=E8s plusieurs
tests, il me semble que la colonne date le p=E9nalise encore plus que
les autres colonnes ...
J'ai essay=E9 de lancer nautilus avec gdb, mais il part dans un
nouveau thread juste avant le moment critique et l=E0 je sais
pas trop faire pour suivre le nouveau thread ...
Quelqu'un a-t-il observ=E9 ce probl=E8me avec nautilus ? des pistes ?
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
Damelo
Guy Roussin a écrit :
Bonjour,
Depuis quelques temps (1 mois?), nautilus est très lent à explorer (à afficher) les répertoires de ma machine (Dell Precision 360, debian etch).
Je constate cette lenteur notamment sur mon homedir (montage nfs) qui contient d'assez nombreux répertoires et fichiers : $ ls -al | wc -l 500
Même lenteur pour les montages smb et les répertoires locaux.
Par exemple, il me faut attendre de 8 à 10 secondes pour que nautilus commence à afficher mon homedir. Pendant ce temps, 100% du cpu est utilisé (roue dentée qui tourne, page blanche). Dès que l'affichage commence, toutes les lignes s'affichent presque immédiatement.
J'ai l'impression que la vitesse d'affichage dépend directement du nombre de lignes et de colonnes à afficher.
Ce qui est remarquable, c'est que sur ces répertoires (et notamment mon homedir) : - l'affichage est immédiat avec un 'ls -al' - l'affichage est immédiat avec konqueror - l'affichage est immédiat sur d'autres PC équipés de debian etch. - un 'du -ks .[a-zA-Z0-9]* *' met moins de 10 secondes et utilise assez peu le cpu sur le homedir.
J'ai testé plusieurs version de kernel (de 2.6.15-1-686-smp à 2.6.18-2-686). Le comportement est le même.
On dirait que c'est la gestion en mémoire vive des entrées qui lui pose problème. Si je cache toutes les colonnes en ne laissant visible que le nom, j'ai une amélioration sensible. Après plusieurs tests, il me semble que la colonne date le pénalise encore plus que les autres colonnes ...
J'ai essayé de lancer nautilus avec gdb, mais il part dans un nouveau thread juste avant le moment critique et là je sais pas trop faire pour suivre le nouveau thread ...
Quelqu'un a-t-il observé ce problème avec nautilus ? des pistes ?
Merci.
Bonjour, Dans le centre de config KDE, mettre sous performance "jamais" pour ne pas réduire l'utilisation de la RAM, sinon, Reiserfs serai + performant en lecture sur de gros volume de petits fichiers...
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Guy Roussin a écrit :
Bonjour,
Depuis quelques temps (1 mois?), nautilus est très lent à explorer
(à afficher) les répertoires de ma machine (Dell Precision 360,
debian etch).
Je constate cette lenteur notamment sur mon homedir (montage nfs)
qui contient d'assez nombreux répertoires et fichiers :
$ ls -al | wc -l
500
Même lenteur pour les montages smb et les répertoires locaux.
Par exemple, il me faut attendre de 8 à 10 secondes pour que nautilus
commence à afficher mon homedir. Pendant ce temps, 100% du cpu est
utilisé (roue dentée qui tourne, page blanche). Dès que l'affichage
commence, toutes les lignes s'affichent presque immédiatement.
J'ai l'impression que la vitesse d'affichage dépend directement
du nombre de lignes et de colonnes à afficher.
Ce qui est remarquable, c'est que sur ces répertoires (et notamment
mon homedir) :
- l'affichage est immédiat avec un 'ls -al'
- l'affichage est immédiat avec konqueror
- l'affichage est immédiat sur d'autres PC équipés de debian etch.
- un 'du -ks .[a-zA-Z0-9]* *' met moins de 10 secondes et utilise
assez peu le cpu sur le homedir.
J'ai testé plusieurs version de kernel (de 2.6.15-1-686-smp à
2.6.18-2-686). Le comportement est le même.
On dirait que c'est la gestion en mémoire vive des entrées qui
lui pose problème. Si je cache toutes les colonnes en ne laissant
visible que le nom, j'ai une amélioration sensible. Après plusieurs
tests, il me semble que la colonne date le pénalise encore plus que
les autres colonnes ...
J'ai essayé de lancer nautilus avec gdb, mais il part dans un
nouveau thread juste avant le moment critique et là je sais
pas trop faire pour suivre le nouveau thread ...
Quelqu'un a-t-il observé ce problème avec nautilus ? des pistes ?
Merci.
Bonjour,
Dans le centre de config KDE, mettre sous performance "jamais" pour ne
pas réduire l'utilisation de la RAM, sinon, Reiserfs serai + performant
en lecture sur de gros volume de petits fichiers...
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Depuis quelques temps (1 mois?), nautilus est très lent à explorer (à afficher) les répertoires de ma machine (Dell Precision 360, debian etch).
Je constate cette lenteur notamment sur mon homedir (montage nfs) qui contient d'assez nombreux répertoires et fichiers : $ ls -al | wc -l 500
Même lenteur pour les montages smb et les répertoires locaux.
Par exemple, il me faut attendre de 8 à 10 secondes pour que nautilus commence à afficher mon homedir. Pendant ce temps, 100% du cpu est utilisé (roue dentée qui tourne, page blanche). Dès que l'affichage commence, toutes les lignes s'affichent presque immédiatement.
J'ai l'impression que la vitesse d'affichage dépend directement du nombre de lignes et de colonnes à afficher.
Ce qui est remarquable, c'est que sur ces répertoires (et notamment mon homedir) : - l'affichage est immédiat avec un 'ls -al' - l'affichage est immédiat avec konqueror - l'affichage est immédiat sur d'autres PC équipés de debian etch. - un 'du -ks .[a-zA-Z0-9]* *' met moins de 10 secondes et utilise assez peu le cpu sur le homedir.
J'ai testé plusieurs version de kernel (de 2.6.15-1-686-smp à 2.6.18-2-686). Le comportement est le même.
On dirait que c'est la gestion en mémoire vive des entrées qui lui pose problème. Si je cache toutes les colonnes en ne laissant visible que le nom, j'ai une amélioration sensible. Après plusieurs tests, il me semble que la colonne date le pénalise encore plus que les autres colonnes ...
J'ai essayé de lancer nautilus avec gdb, mais il part dans un nouveau thread juste avant le moment critique et là je sais pas trop faire pour suivre le nouveau thread ...
Quelqu'un a-t-il observé ce problème avec nautilus ? des pistes ?
Merci.
Bonjour, Dans le centre de config KDE, mettre sous performance "jamais" pour ne pas réduire l'utilisation de la RAM, sinon, Reiserfs serai + performant en lecture sur de gros volume de petits fichiers...
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
