Re: Comment faire pour savoir ce qui rame sur une machine
Aurelien wrote:
> On Tue, Dec 14, 2010 at 03:15:50PM +0100, Xavier Brochard wrote :
>> Aurelien wrote:
>> > On Tue, Dec 14, 2010 at 10:26:28AM +0100, Xavier Brochard wrote :
>> Pour le matériel:
>> lspci -k (montre les drivers)
>
> Heu, c'est marrant, mais pour la carte vidéo, il n'y a pas de driver
> listé. C'est normal ?
non, tu as du le rater; il doit être une ou deux lignes sous "VGA compatible
controller"
> Et, en fait, il n'est pas listé dans lsmod, non plus. Il doit être en
> dur ? (je travaille avec un noyau Debian).
non, il n'est pas en dur, c'est Xorg qui le charge
ou alors tu es en vesa (je _crois_ qu'il n'est pas indiqué)
vesa est lent,
et peut-être encore plus avec Java (pure supposition)?
> Petit truc qui me met la puce à l'oreille aujourd'hui : j'utilise cette
> machine presqu'uniquement pour écrire des partitions et les lire, ainsi
> que lire des vidéos pour mes élèves de basse. J'utilise tuxguitar, qui
> est basé sur Java, et je me demande si c'est pas de là que vient le
> problème. Parce que là, j'ai démarré sans lancer ce paquet, et ça a
> l'air de tourner beaucoup mieux.
c'est possible que Java ou Tuxguitar soit mal configuré.
c'est quel Java? celui de Sun ou celui de Gnu?
Faut tout de même pas tout mettre sur le compte de Java: en 1996 déjà, avec
un P120 MHz 16 Mo de Ram on disait "Java c'est lent, ça ralentit".
Aunjourd'hui on a des monstres. Même toi (comparativement). Sur le serveur
d'à côté, un bi-octo-coeurs, 16 Go de Ram, disques SSD + disques SATA3 en
RAID 10, un assistant me dit encore "ça rame à cause de Java". Et la
marmotte alors?
Bref, vérifie la config, mais ce n'est pas Java en lui même.
> OK, petit bilan, le PC vient de démarrer, XFCE4 lancé, un seul
> xfce4-term de lancé.
> $> free -m
> total used free
> 185 132 53
>
> C'est déjà un peu chaud, j'en ai pas beaucoup sous le coude, mine de
> rien.
tu as oublié une ligne qui commence par "-/+ buffers/cache"
une partie de la ram "utilisée" est en fait un cache pour accélérer les
choses. C'est libéré à la demande.
Par exemple, sur mon portable ça donne:
total used free shared buffers cached
Mem: 1883 1441 442 0 96 688
-/+ buffers/cache: 657 1226
c'est à dire que j'ai encore 1226 Mo sous le coude, et pas 442.
>
> top ordonné par la mémoire me donne le palmarès suivant :
>
> 9% => wicd-client (je ne savais pas que j'avais installé ça, pas trop
> d'intérêt en ce qui me concerne)
> 8.9% => xfdesktop (OK, ça je peux faire sauter)
> 8.7% => Xorg
> 6.3% => xfce4-terminal
> 5.6% => xfce4-panel
> 5.1% => xfce4-menu-plug
> 5% => xfvwm4
> 3.7% => wicd-monitor
> 3.5% => wicd
> 3.3% => xfce4-session
> 3.3% => Thunar (pourquoi ? je n'ai pas de navigateur de fichiers ouvert)
> 2.9% => xfce4-power-management
> 2.3% => xfce4-settings
>
> Grossièrement, XFCE4 bouffe quand même 55% de la RAM à lui tout seul, et
> wicd une quinzaine de pourcent.
non non non
c'est mesuré à l'instant "t" (et mis à jour de façon discrète, pas en
continu). ce n'est pas ce qui est consommé en permanence. CEa dit c'est qand
même bizarre.
> Pour XFC4, je peux virer le bureau, mais virer le panel, etc. ça
> commence à pas ressembler à grand-chose, et donc autant repasser à
> openbox ou icewm.
Un de mes clients est sur un Céléron 1,2GHz, 512 Mo de Ram. Le poste fait
serveur de cients légers avec KDE 3.5.10, ils y a 6 utilisateurs simultanés
dessus, plus des accès rdesktop, des serveurs samba, nfs, cups, httpd, plus
une base de données en perl.
Tu as plutôt un problème de configuration.
Tu devrais vraiment tester avec un CD Live. Prend SystemRescueCD il a des
options intéressantes pour le lancement de l'affichage graphique. Il a des
utilitaires de test du matriel que tu peux lancer au lieu de booter le CD
linux.
xavier
Reply to: