Comment diagnostiquer la montgolfière OS X kernel_task et l'utilisation de la mémoire câblée?

J'ai un problème très étrange, que j'ai du mal à diagnostiquer à la racine.

J'ai un Mac Pro (2008, 8 cœurs 2,8 GHz, 8800GT) avec 14 Go de RAM (récemment mis à niveau à cause de ce problème!).

Lorsque je démarre mon système et que je me connecte, vm_stat / top / Activity Monitor montrera que kernel_task a environ 150 Mo alloués et que la machine a environ 800 Mo de mémoire câblée allouée.

Même au départ, 800 Mo semblent énormément de mémoire câblée à allouer sans aucune application en cours d'exécution - mais cela empire. (NB: le fil est verrouillé, la mémoire ne peut pas être échangée )

Après un temps très court, parfois déclenché par quelque chose d'aussi simple que le lancement d'un terminal, kernel_task montera en flèche à 8-900 Mo de Real Mem (RSIZE) et la mémoire filaire accélérera à 1,6 Go (ce qui implique que toutes les demandes de mémoire supplémentaire sont pour RAM câblée dans le noyau).

Si je quitte tout (IE: aucune application en cours d'exécution, barre un moniteur d'activité ou un terminal pour afficher le dessus), il n'y a pas de réduction appréciable de l'utilisation de kernel_task RSIZE ou de la mémoire câblée. Aller dans le sens inverse et charger le système avec des tâches montre également que la mémoire câblée n'est pas réduite - et surtout qu'elle n'est pas réduite de préférence à un échange lourd.

Si je me déconnecte et me reconnecte, cela réduit un peu (450 Mo kernel_task, 1,28 Go câblé), mais pas au début.

Je n'exécute aucun kext wacky - et en outre, kextstat ne montre aucune allocation de mémoire énorme là-bas; le plus grand étant com.apple.nvidia.nv50hal avec environ 4 Mo de mémoire.

La machine semble globalement plus lente lorsque cela s'est produit - sans surprise, car une telle quantité de RAM a été marquée comme non paginable.

J'ai donc quelques questions:

1) Existe-t-il un bon moyen de diagnostiquer ce qui a alloué toute cette mémoire filaire? C'est souvent plus de 2 fois la taille de kernel_task, n'exécutant aucune application. Le total réel de la mémoire ne semble pas s'additionner - il semble qu'il y ait un tas de RAM qui n'est pris en compte nulle part.

2) Que se passe-t-il pour que le noyau nécessite soudainement 6 fois plus de mémoire?

Pour rechercher pourquoi le noyau utilise plus de mémoire que d'habitude, vous pouvez utiliser différents outils.

1. Exécutez le Moniteur d'activité pour vérifier quels processus utilisent le plus de mémoire, c'est donc une kernel_tasktâche, pas une autre tâche utilisant plus de mémoire que d'habitude (alors envisagez de la tuer).
2. Exécutez dans Terminal vm_stat 1pour voir les statistiques de mémoire en temps réel et si votre mémoire augmente vraiment à chaque seconde.
3. Exécutez l' fs_usageoutil (en tant que root) pour surveiller les appels système et les erreurs de page en temps réel.

4. Pour vérifier la somme des allocations sales / anonymes de plusieurs processus exécutés dans le terminal:

   sudo footprint -all -categories -swapped -collapseSharing
   

   Il rassemblerait des informations sur la mémoire telles que la quantité de mémoire échangée (par utilisateur ou mémoire du noyau).

5. De plus, si vous pensez que c'est le noyau qui utilise le plus de mémoire, essayez l' zprintoutil:

   sudo zprint -t -s | head -n20
   

   Il affichera les informations sur les zones du noyau

Si vous souhaitez forcer la purge du cache disque (pour libérer de la mémoire), vous pouvez essayer:

sync && sudo purge

Voir aussi: Comment enquêter sur l'utilisation élevée de la mémoire des tâches du noyau? à AD SE

Les extensions du noyau ne sont que l'un des nombreux, nombreux, nombreux fragments de code qui peuvent être exécutés par le système d'exploitation à votre insu. J'ai un petit utilitaire basé sur Python appelé Consultant's Canary qui vous aidera à en trouver un certain nombre:

• Lien archivé
• Lien de documentation 1
• Documentation / Lien de téléchargement 2

Si cela ne révèle aucun coupable potentiel, je dirais que démarrer à partir d'une installation propre et voir si vous pouvez reproduire le problème là-bas.