OVH Cloud OVH Cloud

charge machine > 1

19 réponses
Avatar
Hugolino
[x-post : fcolc + fcsp ; fu2 : fcolc ]

Yo !!

Un portable (MSI-1681E) tout nouveau tout beau avec 4GB de ram et un proc
i5-460M sur lequel je viens d'installer une arch linux 2010.05 sous KDE
4.6.1.

(Arch est une distro 'rolling release' et elle est à jour avec par
exemple un noyau 2.6.37 du 25/03/2011)

La charge machine ne descend jamais en dessous de 100%, exemple:
$ top -bn 1 | head -n 15
8<-----------8<---------8<----------8<----------8<----------8<----------8<
top - 14:55:30 up 12:12, 2 users, load average: 1.03, 1.06, 1.11
Tasks: 165 total, 1 running, 164 sleeping, 0 stopped, 0 zombie
Cpu(s): 9.1%us, 2.2%sy, 0.3%ni, 87.2%id, 1.1%wa, 0.0%hi, 0.1%si,0.0%st
Mem: 3841052k total, 3745220k used, 95832k free, 227992k buffers
Swap: 4883724k total, 0k used, 4883724k free, 2543824k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2994 root 20 0 291m 51m 10m S 10 1.4 11:32.62 Xorg
3299 hugo 20 0 873m 67m 32m S 8 1.8 8:02.40 plasma-desktop
3420 hugo 20 0 855m 226m 35m S 8 6.1 2:16.19 konqueror
3289 hugo 20 0 576m 47m 32m S 6 1.3 5:21.79 kwin
3306 hugo 20 0 8972 1076 740 S 4 0.0 1:03.57 ksysguardd
3344 hugo 20 0 210m 12m 9928 S 2 0.3 0:47.71 gkrellm
6565 hugo 20 0 10784 1164 840 R 2 0.0 0:00.01 top
1 root 20 0 3916 632 540 S 0 0.0 0:01.33 init
8<-----------8<---------8<----------8<----------8<----------8<----------8<

Par comparaison, la même commande sur une debian/lenny installé sur un
PC à base de Celeron@2700MHz datant de 2005 raconte:
8<-----------8<---------8<----------8<----------8<----------8<----------8<
top - 14:56:37 up 18 days, 10:17, 3 users, load average: 0.12, 0.30, 0.37
Tasks: 179 total, 2 running, 177 sleeping, 0 stopped, 0 zombie
Cpu(s): 16.5%us, 3.5%sy, 2.2%ni, 75.7%id, 1.7%wa, 0.2%hi, 0.2%si, 0.0%st
Mem: 775936k total, 727712k used, 48224k free, 14712k buffers
Swap: 1052216k total, 182304k used, 869912k free, 139892k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26709 hans 20 0 413m 280m 19m R 13.5 37.0 78:48.11 firefox-bin
1658 hugo 20 0 2420 1100 800 R 3.9 0.1 0:00.02 top
23060 www-data 20 0 25468 6176 2488 S 3.9 0.8 0:01.04 apache2
1 root 20 0 2016 576 552 S 0.0 0.1 0:18.24 init
2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
4 root 15 -5 0 0 0 S 0.0 0.0 2:31.92 ksoftirqd/0
5 root RT -5 0 0 0 S 0.0 0.0 0:05.36 watchdog/0
8<-----------8<---------8<----------8<----------8<----------8<----------8<

J'ai soupçonné la carte wifi (une Ralink 3090 que je galère à faire
fonctionner) de mettre le bronx dans le bus, mais même quand je la
désactive avec une combinaison de touches (via le BIOS donc) ou avec
rfkill, la charge ne descend jamais en dessous de 100%.

Quelles commandes/quels fichiers de log faut-il exécuter/examimer pour
déterminer ce qui charge la machine comme ça ?

Ça ne rend pas ce PC inutilisable puisque le calcul de la charge est
fait en prenant en compte les quatre (pseudos) processeurs, mais je me
dis que ça relève soit d'un problème hard, soit d'une mauvaise
configuration d'un daemon.


Merci de votre aide.


--
> je voudrais pirater la fac ou je suis qui est sur réseau sur linux!
echo "rpub \"w'nv yr cnffjbeq ebbg!\"|znvy ebbg" |tr a-mn-z n-za-m|/bin/sh
Hugo (né il y a 1 480 772 665 secondes)

9 réponses

1 2
Avatar
Éric Jacoboni
Le 28/03/2011 15:10, Hugolino a écrit :

Un portable (MSI-1681E) tout nouveau tout beau avec 4GB de ram et un proc
i5-460M sur lequel je viens d'installer une arch linux 2010.05 sous KDE
4.6.1.

La charge machine ne descend jamais en dessous de 100%, exemple:



Le problème semble résolu... Il s'agissait d'un bug de ntrack avec KDE...

Une mise à jour du paquet ntrack devrait faire l'affaire.
Avatar
Hugolino
Le 06-04-2011, Éric Jacoboni a écrit :
Le 28/03/2011 15:10, Hugolino a écrit :

> Un portable (MSI-1681E) tout nouveau tout beau avec 4GB de ram et un proc
> i5-460M sur lequel je viens d'installer une arch linux 2010.05 sous KDE
> 4.6.1.

> La charge machine ne descend jamais en dessous de 100%, exemple:

Le problème semble résolu... Il s'agissait d'un bug de ntrack avec KDE...



Il me semble que tu confuses...
<https://bugs.archlinux.org/task/23612> parle d'un bug entre kded et
ntrack dans sa version 14 qui entraine une charge *cpu* de 100% (et ça
semble donc lié à ce que je raconte dans mon autre message).

Une mise à jour du paquet ntrack devrait faire l'affaire.



Sauf que pacman ne me propose pas de mise à jour et que je n'utilise pas
la version 14 mais la 13:
# pacman -Ss ntrack
extra/ntrack 1:13-1 [installé]
(que je viens de réinstaller depuis extra)

Sais-tu comment obtenir d'autres versions de ntrack ? AUR ne semble pas
proposer ce PKGBUILD.

J'ai trouvé <https://launchpadlibrarian.net/68231891/ntrack-link.patch>
mais (la vieillesse est un naufrage) je ne sais plus comment faire pour
appliquer un patch ;-))

Ma question (plus générale) reste entière : comment faire pour
déterminer la raison de cette charge élevée ? Quels outils utiliser ?


Merci à toi.


--
It looks as if noone with a 64 bit machine has gotten bitten by this yet


Well, in order to get bitten by this you have to have a 2-terabyte IDE
disk, so we don't have to worry about it for another few months..
-+- Linus in Guide du linuxien pervers - J'ai déjà entendu ça quelque part"
Avatar
Éric Jacoboni
Le 08/04/2011 12:47, Hugolino a écrit :

Sauf que pacman ne me propose pas de mise à jour et que je n'utilise pas
la version 14 mais la 13:
# pacman -Ss ntrack
extra/ntrack 1:13-1 [installé]
(que je viens de réinstaller depuis extra)



Comme dit plus haut, je n'utilise pas KDE : je n'ai fait que relayer des
constatations trouvées sur les forums Arch Linux où des Kdeistes
annonçaient que le nouveau paquet avait résolu leur prb de charge.

Sais-tu comment obtenir d'autres versions de ntrack ? AUR ne semble pas
proposer ce PKGBUILD.



Ben, à part le recompiler à partir des sources, je ne vois pas...

J'ai trouvé<https://launchpadlibrarian.net/68231891/ntrack-link.patch>
mais (la vieillesse est un naufrage) je ne sais plus comment faire pour
appliquer un patch ;-))



Au hasard, avec la commande "patch" ? :)

Sinon, tu as essayé sans KDE ? Le problème est le même ?
Avatar
Hugolino
Le 08-04-2011, Éric Jacoboni a écrit :
Le 08/04/2011 12:47, Hugolino a écrit :

[...]

> Sais-tu comment obtenir d'autres versions de ntrack ? AUR ne semble pas
> proposer ce PKGBUILD.

Ben, à part le recompiler à partir des sources, je ne vois pas...



OK.

> J'ai trouvé<https://launchpadlibrarian.net/68231891/ntrack-link.patch>
> mais (la vieillesse est un naufrage) je ne sais plus comment faire pour
> appliquer un patch ;-))

Au hasard, avec la commande "patch" ? :)



Oui, mon alzheimer n'est pas encore à un stade aussi avancé... (et
relire un peu de doc me rajeunira)

Sinon, tu as essayé sans KDE ? Le problème est le même ?



Oui. J'ai essayé après avoir blacklisté kdm dans la ligne DAEMONS du
rc.conf, donc sans interface graphique et même en init 1. C'est pour ça
que j'ai besoin d'outils pour diagnostiquer l'origine de cette charge
(qui n'est pas d'origine cpu).
Je me demande si mon portable ne souffre pas d'un problème matériel.


--
J'avais réussi à trouver un disciple, ça peut servir quand je monterai
ma secte des adorateurs du pingouin. Au programme, rétablissement de la
Sainte Inquisition et combustion des suppôts de MS.
Hugo (né il y a 1 481 736 825 secondes)
Avatar
Jo Engo
Bonjour, lundi 28 mars 2011 à 15:10:01, dans le(s) forum(s)
fr.comp.os.linux.configuration,fr.comp.sys.pc, Hugolino a proposé :

87.2%id,



Un cpu à 100% qui est au repos à 87.2% c'est assez balaise :o)
--
http://www.bidart.net/anniversaire
Avatar
Hugolino
Le 10-04-2011, Jo Engo a écrit :
Bonjour, lundi 28 mars 2011 à 15:10:01, dans le(s) forum(s)
fr.comp.os.linux.configuration,fr.comp.sys.pc, Hugolino a proposé :

> 87.2%id,

Un cpu à 100% qui est au repos à 87.2% c'est assez balaise :o)



Tu trouve ça "assez balaise" parce que tu confonds charge machine avec
temps processeur : ce n'est tout simplement pas la même chose, car un
ordinateur n'est pas constitué que d'un (ou plusieurs) processeur...

Voilà ce que je disais:

> La charge machine ne descend jamais en dessous de 100%, exemple:
> $ top -bn 1 | head -n 15
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<
> top - 14:55:30 up 12:12, 2 users, load average: 1.03, 1.06, 1.11


****************
> Tasks: 165 total, 1 running, 164 sleeping, 0 stopped, 0 zombie
> Cpu(s): 9.1%us, 2.2%sy, 0.3%ni, 87.2%id, 1.1%wa, 0.0%hi, 0.1%si,0.0%st




--
Déconner, c'est se vider de la connerie acquise par osmose.
Hugo (né il y a 1 482 312 136 secondes)
Avatar
Benoit Izac
Dans le message , le 28/03/2011 à 19:52, j'ai
écrit :

J'ai aussi le cas sur le portable du boulot lorsque je boot dessus avec
mon disque dur USB qui contient ArchLinux. Je ne sais pas si c'est du
à la machine ou au fait que je sois en USB mais j'ai la même chose :
% uptime
19:51:16 up 25 min, 0 users, load average: 1.00, 1.06, 1.09

Après, ça ne change pas grand chose : ni la mémoire ni le cpu ne sont
affectés, et aucune différence avec une charge à 0. Faudrait que je
mette mon disque sur mon portable qui a archlinux sur le disque interne
pour voir si ça vient de la machine (pas possible avant ce week-end).



J'ai pas pu faire de test plus tôt mais, depuis la mise à jour que j'ai
faite hier (kernel 2.6.37 -> 2.6.38), le problème n'existe plus.

--
Benoit Izac
Avatar
Hugolino
Le 17-04-2011, Benoit Izac a écrit :
Dans le message , le 28/03/2011 à 19:52, j'ai
écrit :

> J'ai aussi le cas sur le portable du boulot lorsque je boot dessus avec
> mon disque dur USB qui contient ArchLinux. Je ne sais pas si c'est du
> à la machine ou au fait que je sois en USB mais j'ai la même chose :
> % uptime
> 19:51:16 up 25 min, 0 users, load average: 1.00, 1.06, 1.09
>
> Après, ça ne change pas grand chose : ni la mémoire ni le cpu ne sont
> affectés, et aucune différence avec une charge à 0. Faudrait que je
> mette mon disque sur mon portable qui a archlinux sur le disque interne
> pour voir si ça vient de la machine (pas possible avant ce week-end).

J'ai pas pu faire de test plus tôt mais, depuis la mise à jour que j'ai
faite hier (kernel 2.6.37 -> 2.6.38), le problème n'existe plus.



Je confirme. Et en plus, le wifi de mon portable (une Ralink RT3090)
fonctionne maintenant correctement.

Peut-être la charge toujours supérieure à 1 venait-elle d'une
loufoquerie dans le driver i915 de la carte graphique intel qui
s'amusait à répéter sans fin "[drm:intel_panel_get_max_backlight]
*ERROR* fixme: max PWM is zero."
Avais-tu une telle carte ?


--
Maintenant que je commence a me debrouiller pas mal en Perl, c'est
promis, je vais reflechir a un nouveau programme qui aurait pour charge
de filtrer la connerie sur les News.
Hugo (né il y a 1 482 567 966 secondes)
Avatar
Benoit Izac
Bonjour,

le 20/04/2011 à 23:11, Hugolino a écrit dans le
message :

Peut-être la charge toujours supérieure à 1 venait-elle d'une
loufoquerie dans le driver i915 de la carte graphique intel qui
s'amusait à répéter sans fin "[drm:intel_panel_get_max_backlight]
*ERROR* fixme: max PWM is zero."
Avais-tu une telle carte ?



J'ai bien une Intel sur cette machine :
00:02.0 VGA compatible controller [0300]: Intel Corporation Core
Processor Integrated Graphics Controller [8086:0046] (rev 12)

mais en revanche
# grep intel_panel_get_max_backlight /var/log/everything.log*
ne donne pas de résultat.

Mon portable qui possède aussi une carte Intel, n'a jamais eu ce
problème donc je n'en ai aucune idée de l'origine du problème.

--
Benoit Izac
1 2