Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[Résolu] F18 gourmande en CPU ?

ciaparis

Dans un décor XCFE ou GNOME, sur 6 PC d'installés bi-core à quad-core, Fedora 18 fait travailler le CPU à 100% en alternance sur un des "cœurs" et sans application de lancée.

Depuis quelques jours, je m'esquinte les yeux à lire et à essayer tout ce qui a trait aux services qui pourraient "pomper" sur le CPU. J'avoue qu'au bout de mes recherches, ça s'embrouille pas mal tant j'ai ouvert de pistes pour trouver le service coupable qui empêche mes applications Java de tourner "normalement" comme c'est le cas depuis la Fedora 3.

Faites l'essai en lançant gnome-system-monitor et si vous n'êtes pas étonné de cette gourmandise ou que vous n'obtenez pas cette suractivité de CPU, merci de me le faire savoir car je vais finir dans un break-down 🙁

VINDICATORs

Que retourne la commande "top" en ligne de commande?

A tout les coups c'est l'indexation du disque qui te pose problème. Regarde avec la commande dmesg si ça ne rapporte pas d'erreur.

ciaparis

VINDICATORs wrote:Que retourne la commande "top" en ligne de commande?

20453 root 20 0 5220 1312 968 R 0,3 0,1 0:00.18 top

N. B. Il s'agit, bien entendu, de la ligne éditée en gras par la commande dmesg. Je remarque tout de même que la mesure CPU donnée par la commande dmesg est plus en rapport avec ce que je connais d'un CPU que la mesure de gnome-system-monitor qui affiche des poussées de fièvre inquiétantes :-?

VINDICATORs wrote:A tout les coups c'est l'indexation du disque qui te pose problème. Regarde avec la commande dmesg si ça ne rapporte pas d'erreur.

Voici les deux "erreurs" que j'ai repéré.

ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [_S2_
] (20130117/hwxface-568)
[ 0.045105] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [_S3_
] (20130117/hwxface-568)

Je ne sais pas si cela correspond à l'indexation du disque mais cela reste très étonnant car le même symptôme se produit sur d'autres configurations de capacités et de tailles différentes. Je viens d'installer une F16 et l'activité CPU est complètement normale. Je vais donc creuser la piste 'indexation disque' mais je suis preneur d'explications complémentaires.

Merci et A bientôt

VINDICATORs

Oui mais là je ne vois pas qui te mange des ressources!

Que retourne la commande "top"?

paradise

En s'y reprenant plusieurs fois, on arrive à faire un copier-coller des infos de la commande "top", mais remarques-tu un processus en particulier qui bouffe des ressources CPU ?

ciaparis

VINDICATORs wrote:Oui mais là je ne vois pas qui te mange des ressources!

Que retourne la commande "top"?

Voici un fragment du top. Toutes mes excuses pour la longueur du texte ci-après

top - 10:26:01 up 4 min, 2 users, load average: 0,68, 0,78, 0,38
Tasks: 188 total, 2 running, 186 sleeping, 0 stopped, 0 zombie
%Cpu(s): 50,0 us, 1,9 sy, 0,0 ni, 48,1 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 2065108 total, 758560 used, 1306548 free, 55172 buffers
KiB Swap: 4128764 total, 0 used, 4128764 free, 398964 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1404 root 20 0 155m 48m 17m R 98,1 2,4 0:44.51 Xorg
1748 dan 20 0 141m 12m 9,8m S 1,9 0,6 0:00.55 metacity
1903 dan 20 0 172m 12m 9,9m S 1,9 0,6 0:00.23 wnck-applet
2105 dan 20 0 187m 15m 11m S 1,9 0,8 0:00.43 gnome-terminal
1 root 20 0 8136 5552 2332 S 0,0 0,3 0:01.43 systemd
2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 0:00.02 ksoftirqd/0
4 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0
5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kworker/u:0
7 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/u:0H
8 root rt 0 0 0 0 S 0,0 0,0 0:01.17 migration/0
9 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh
10 root 20 0 0 0 0 S 0,0 0,0 0:00.13 rcu_sched
11 root rt 0 0 0 0 S 0,0 0,0 0:00.00 watchdog/0
12 root rt 0 0 0 0 S 0,0 0,0 0:00.00 watchdog/1
13 root rt 0 0 0 0 S 0,0 0,0 0:02.11 migration/1
14 root 20 0 0 0 0 S 0,0 0,0 0:00.00 ksoftirqd/1
15 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kworker/1:0
16 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/1:0H
17 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 khelper
18 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kdevtmpfs
19 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 netns
20 root 20 0 0 0 0 S 0,0 0,0 0:00.00 bdi-default
21 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kintegrityd
22 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kblockd
23 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 ata_sff
24 root 20 0 0 0 0 S 0,0 0,0 0:00.00 khubd
25 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 md
26 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kworker/1:1
28 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kswapd0
29 root 25 5 0 0 0 S 0,0 0,0 0:00.00 ksmd
30 root 20 0 0 0 0 S 0,0 0,0 0:00.00 fsnotify_mark
31 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 crypto

ciaparis

paradise wrote:En s'y reprenant plusieurs fois, on arrive à faire un copier-coller des infos de la commande "top", mais remarques-tu un processus en particulier qui bouffe des ressources CPU ?

A part Xorg, je n'ai rien vu d'autre qui fagocite le CPU. Cela fait plus de 10 jours que je "track" le service en cause 🙁

Après maintes observations, je peux dire que la surcharge du CPU est provoquée par le lancement de l'utilitaire gnome-system-monitor :-o qui sollicite Xorg à tel point que celui-ci monte à 100% d'occupation CPU.

Avec l'utilitaire glances, les mesures CPU sont différentes et sans lancer d'application, l'activité du CPU est normale. Dommage que l'on ne puisse pas montrer des captures d'écran. Par conséquent, mon problème de JVM reste entier.

paradise

Pourquoi ne peux-tu pas faire de captures d'écran ?

edit : utilise les balises code quand tu as un texte à rapporter.

ciaparis

paradise wrote:Pourquoi ne peux-tu pas faire de captures d'écran ?

edit : utilise les balises code quand tu as un texte à rapporter.

Effectivement, j'avais zappé la possibilité d'utiliser la balise "edit". Mais je viens d'effectuer une mise à jour de toutes mes F18 et comme par magie, mon problème est à présent résolu avec les derniers paquets. Certains paquetages portent sur DBUS, sur le Kernel, sur X11 et sur certains services.

Du coup, gnome-system-monitor ne délire plus et affiche les mêmes mesures que l'excellent utilitaire "glances" et ma JVM + mes applications fonctionnent comme avant, et peut-être même mieux. J'ai pratiqué des tests (grosses requêtes, instanciations, threads à gogo, gros calculs, etc..) pour jauger le système et aucune application n'a "freezé".

En conclusion, je suis heureux car mon client a retrouvé le sourire grâce à votre aide et aux "upgrades" de Fedora 🙂

Merci à tous. :pint: