kernel_task encore en surdose de RAM?

[havez]

Bonsoir à tous!
Aujourd'hui, après l'installation de Lion, j'ai remarqué que le fameux processus kernel_task, qui comme sous 10.6.8 avait le même problème, continue à prendre beaucoup de RAM sur lui-même (en moyenne autour de 300-500Mo).

Est-ce toujours normal?
Est-ce que vous aussi vous avez le même problème?


Merci d'avance pour vos réponses

Havez

 

[havez]

Bump

 

[just1]

idem pour moi!
kernel_task me prend 644,5Mo de mémoire!

Est ce normal? Y a t-il quelque chose à faire?
Merci

 

[havez]

Remontée en tête de gondole

 

[nifex]

Moi aussi depuis le passage a Lion le kernel_task atteint presque les 700 mo de ram...

 

[havez]

Remontée pour la journée!

 

[just1]

Je tourne actuellement à 704 mo aussi!

Juste Firefox et Twitter d'ouvert!
Aucun accès disque ni échange de données...

D'autres personnes peuvent elles nous dire a combien tourne le "kernel_task" chez eux sous Lion?

Merci

 

[itryp]

C'est dans ces eaux la pour moi aussi...

 

[bompi]

806 MB pour kernel_task sur mon MBP.

 

[Crock-Man]

Pareille pour moi, entre 360 / 600 Mo, de même avec 10.6.8, par contre 10.6.7 pas plus de 240Mo, j'aimerais bien comprendre ?

 

[havez]

4ème remontée pour ce topic

Soit dit en passant, j'ai trouvé (et acheté) un magnifique petit utilitaire au top des ventes sur le Mac App Store (0,79€ au lieu de 7,99€ pour la semaine) permettant de libérer la mémoire inactive non libérée par certaines applications (et en général par le système).
Et je peux vous assurez que ça m'a fait un bien fou en plein travail sous FCP ou sur TF2

Lien vers le Store (ceci n'est pas un post promotionnel, juste en relation avec mon problème )

 

[Crock-Man]

Le problème c'est pas de purger la mémoire, le principe de la gestion de la mémoire sous OS X fonctionne de manière tardive, sa a un nom bien précis mais là je sais plus :rose: bref, même si 90% semble occupé c'est pas grave, se qui est plus gênent c'est si la memoir n'est pas libéré si un logiciel en a besoin.

Mais il me semble que les taches du noyaux sont particulièrement gourmande, c'est là que j'aimerais une explication, et vu le nombre de personne qui on se souci, il ne s'agit pas d'un conflit de pilote ou un truc du genre, est il possible que Apple est compilé le noyau avec une attention particulière pour les systèmes de derniers génération en occultant quelque peut les problème rencontrè avec les anciens systèmes ( plus de 12 mois ) j'espère que non.

Quand au logiciel que tu propose, c'est vrai il est pas cher, mais Onyx fait sa déjà trés bien.

 

[ChristOff]

Je m'agrippe à ce topic pour signaler que j'ai moi aussi ce problème de kernel_task qui utilise une quantité invraisemblable de RAM (+/- 800Mo réél et 5Go virtuel en ce moment sous 10.6.8). J'ai l'impression que c'est fonction de la quantité de RAM totale. En effet, je suis passé à 8Go récemment, contre 4 précédemment, et la quantité de RAM de kernel_task semble avoir suivi le même chemin x2 (mais c'était en 10.6.7).

La purge via Onyx (et l'autre prog cité) ne sert à rien dans ce cas (vu que la mémoire n'est pas inactive).


Y-a-t-il moyen de lister ce qui est contenu dans kernel_task (une liste des extensions et drivers chargés avec leur occupation RAM respective, etc) ? Le cache disque est-il compris dans kernel_task ?


ChristOff

 

[bompi]

Pour les extensions : kextstat. Pour la mémoire, il y a vm_stat au global et vmmap pour un processus.
Il y en a encore une autre mais je ne m'en souviens plus :rateau:

 

[ChristOff]

Merci pour ta réponse.



Pour kextstat, le plus gros driver/extension, chez moi, c'est le driver nvidia qui consomme +/- 4Mo (4210688 bytes - 0x404000 bytes en affichage hexa - pour com.apple.nvidia.nv50hal). Tous les autres sont nettement plus petits pour la plupart d'entre eux (de l'ordre de moins de 50Ko); au total, j'ai 128 extensions chargées, dont 6 non apple (littlesnitch, soundflowers et 4x vmware).



Pour vm_stat, c'est pas super causant (je n'arrive pas à déterminer ce qui est parlant dans l'output en fait )

Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free:                         962212.
Pages active:                       498154.
Pages inactive:                     126846.
Pages speculative:                  209086.
Pages wired down:                   234906.
"Translation faults":            209638781.
Pages copy-on-write:               3082784.
Pages zero filled:               143544236.
Pages reactivated:                       3.
Pageins:                            246224.
Pageouts:                                0.
Object cache: 33 hits of 681660 lookups (0% hit rate)

Ca me dit 498.154 pages de 4Ko actives (ça fait donc 1.992.616Ko -> quasi 2Go) ce qui colle avec ce que raconte le moniteur d'activité. Mais où dans ces chiffres vois-je l'utilisation de la mémoire réservée pour le cache disque? Bref comment interpréter ce bazard? D'après le man, la définition de wired down devrait coller avec "résidente" dans le moniteur d'activité, hors c'est pas le cas (1,15go reporté de ce côté, contre 234.906x4 - 939.624 - Ko dans vm_stat), manquent donc +/- 50.000 pages, que je ne trouve nulle part.


Pour ce qui est de vmmap, je n'arrive pas à le faire sur kernel_task; "ps aux" ne me donne aucun processus 0 (le plus bas étant 1 - launchd) et vmmap kernel_task me donne "pas de processus avec ce nom" (ce que je confirme, y a pas dans l'ouput de ps aux).

 

[bompi]

En effet, je ne sais pas comment on peut attraper des informations sur kernel_task. J'ai cherché et vu un certain nombre de commandes mais elles tournent autour des mêmes données et semblent ne pas savoir traiter le process 0 (kernel_task).
Je suis sec.

 

[ChristOff]

Goch...
Merci de tes investigations.


En attendant qu'un OSxKernelGuru passe dans le coin, on en est donc réduit à "c'est comme ça"

 

[Jaxter0ne]

Même problème chez moi! Vivement que quelqu'un ait une solution, parce que ça raaaaaame! :sleep:

 

[delmic]

Chez moi, actuellement et après relance de ma session : kernel_task = 403,6 Mo ...

Mais j'ai découvert ce post car je constate depuis peu, et après 1 mois d'utilisation intensive de Lion, que la part verte de la roue de Moniteur d'activité se réduit comme "peau de chagrin" :

Lorsque je redémarre (ou que je relance ma session), j'ai au départ 2 Go (sur 4 au total) dispos (en vert).

Au fur et à mesure de l'utilisation :
- la part "active" grimpe allègrement
- l'"inactive" et la "résidente" sont stables
- par conséquent, la part "disponible" fini par quasi-disparaitre (100 Mo ou moins)

J'ai d'abord mis cela sur le dos du nombre d'applis que j'ai tendance à laisser tourner sans les quitter, mais en les fermant, je n'ai pas constaté de changement significatif.

J'ai ensuite cherché à voir qui consommait quoi, et j'ai immédiatement repéré en champion toute catégorie : kernel_task (à quelques 800Mo )​

C'est bizarre, j'ai l'impression de me retrouver sur mon Palm TX de la grande époque, dont la fragmentation de la mémoire vive imposait régulièrement des reboots ...

Reste que même avec reprise et compagnie, c'est un rien agaçant de devoir relancer régulièrement sa session pour travailler efficacement plus de quelques heures

 

[FrançoisMacG]

Peut-être la bonne réponse là :

The first is to disable any hardware devices you may have attached to your system, such as external monitors, hard drives, or third-party audio or video interfaces. In addition, you can disable services like Wi-Fi and Bluetooth if you are not using them, and switch to using discrete graphics instead of the onboard GPU.
The second thing you can do is quit programs and system services that use kernel extensions, such as the aforementioned Photo Booth, or graphics processing programs and games, especially if you are running with the integrated graphics card.