Pourquoi la fuite de mémoire semble-t-elle s’appliquer à kernel_task et pourquoi OS X ne peut-elle pas être collectée?

11

On m'a dit précédemment que certaines applications présentaient une fuite de mémoire, à savoir kernel_taskune empreinte mémoire importante, généralement de l'ordre du gigaoctet. Si un problème apparaissait kextcausait cette utilisation de la mémoire, nous nous attendrions à voir une différence entre la mémoire allouée et celles qui devraient être allouées, c'est-à-dire

diff <(kextstat|tr -s ' ' | cut -d ' ' -f 5) <(kextstat| tr -s ' ' | cut -d ' ' -f 6) 

renverrait autre chose que les mots "Wired" et "Name".

Lors de la rédaction de ma thèse, j’ai constaté que le fait de modifier un fichier PDF pendant qu’il est ouvert dans Preview entraînait souvent de graves problèmes: parfois, l’utilisation de la mémoire kernel_taskpeut atteindre environ huit gigaoctets, voire davantage. Si je tue l'aperçu, il revient instantanément à la normale . Il est donc évident que quelque chose ne va pas - et Preview perd de la mémoire dans ces conditions.

Ma question est donc la suivante: si je sais qu’un processus a perdu de sa vigueur grâce à une augmentation soudaine et inattendue de l’empreinte de kernel_task, pourquoi OS X ne peut-il pas savoir que quelque chose ne va pas. Si kill Preview restaure ma malloc()mémoire manquante , pourquoi Darwin ne collecte- t- il pas automatiquement les ordures pour moi?

Ai-je un malentendu fondamental sur le fonctionnement de la gestion de la mémoire?

EDIT: (15/9/15)

Voici une démonstration de ce dont je parle. Tout d’abord, je remarque une utilisation importante de la mémoire par kernel_task(remarque, l’aperçu est ouvert, mais visible au bas de Activity Monitor, avec 333 Mio de RAM):

Utilisation élevée de la mémoire du noyau

Après les remarques utiles de Ashley ci-dessous, voyons combien chaque kext utilise:

$ kextstat | awk 'NR==1{ printf "%10s %s\n", $5, $6; } NR!=1{ printf "%10d %s\n", $5, $6; }' | sort -n

...
...
...
   1249280 com.apple.driver.DspFuncLib
   1769472 com.apple.nvidia.driver.NVDAGK100Hal
   2629632 com.apple.nvidia.driver.NVDAResman
   6184960 com.apple.driver.AirPort.Brcm4360
$

Donc pas beaucoup. Ma machine a des GPU discrets et intégrés. leurs conducteurs utilisent seulement quelques Mo de RAM câblé. Sur mon intuition, éliminons Preview et voyons ce qu'il advient de l'empreinte mémoire de kernel_task:

Tuer l'aperçu aide les choses

La prévisualisation a disparu et l'encombrement mémoire du noyau a considérablement diminué. Il n'y a toujours aucune preuve d'un changement dans l'utilisation de kext: le résultat de la commande ci-dessus reste inchangé.

Edit : Bug signalé sous le N ° 22701036. J'attends toujours une réponse d'Apple. Il n'y a rien de particulièrement intéressant si vous inspectez le processus dans ActivityMonitor, mais il me manque peut-être quelque chose.

Landak
la source
Je suis confus sur deux choses - pourriez-vous préciser? 1) Je pense que votre diffcommande compare les colonnes Sizeet Wiredde la kextstatsortie. Je conviens qu’il Sizes’agit de "mémoire allouée", mais je ne pense pas qu’elle Wiredsoit "censée être allouée" (la man kextstatdécrit comme "le nombre d’octets câblés de la mémoire du noyau occupée par le kext"). 2) Voyez-vous la différence entre Sizeet Wiredquand vous avez le problème avec Preview?
Ashley
1) Vous avez raison - je compare les éléments dans Taille et Câblé à partir de kextstat. Je crois comprendre que si un kext fuit, les octets alloués et ceux que le noyau sait sont attribués sera différent. Dans ce cas, j'ai mis cela là pour montrer que je n'ai pas de kext qui fuit - donc, 2) cela ne se produit pas lorsque Preview mange du ram. Au lieu de cela, kernel_taskgrandit beaucoup. Je vais essayer de recréer ce problème et de prendre une photo :-).
Landak
Merci! Attendez une seconde: je suis en train d'écrire une réponse qui pourrait aider.
Ashley

Réponses:

6

Le noyau d’OS X n’est pas récupéré; Le libkern C ++ Runtime d'IOKit exige des développeurs qu'ils gèrent leur propre mémoire.

Gestion de la mémoire Mac

De Comment fonctionne la gestion de la mémoire sous Mac OS X?

Apple documente assez bien les niveaux les plus bas du noyau Mach et du sous-système de mémoire virtuelle sur le Web, en tant que partie de la documentation destinée aux développeurs.

Depuis que ce noyau a été développé par l'Université Carnegie Mellon , vous pouvez trouver des dizaines d' articles le décrivant assez facilement.

Autres sources

Collecte des ordures

La récupération de place existe au niveau de l'utilisateur ou de l'application. Même au niveau de cette couche, la récupération de place n'aide que si l'application a libéré toutes les revendications dans la mémoire. Une dépendance circulaire peut vaincre la récupération de place. La collecte des ordures ménagères est en soi un domaine de recherche en pleine évolution et difficile à maîtriser .

Signaler des bugs et des fuites de mémoire

Les bogues dans OS X perdront de la mémoire. Compte tenu de la taille de la base de code, c'est presque certain.

Veuillez signaler les bogues reproductibles directement à Apple . Chaque rapport de bogue aide et peut-être que votre exemple sera celui qui aide les ingénieurs d’Apple à cerner la cause.

Graham Miln
la source
C'est décevant, mais sans aucun doute correct. J'ai signalé le bogue à Apple - je trouve cela simplement agaçant!
Landak
2
S'il vous plaît pouvez-vous partager le numéro de bogue comme une édition à votre question. Les autres utilisateurs qui trouvent votre question utile peuvent alors classer les bogues en double en notant l’original. Un tas de bogues liés aidera à justifier plus de temps d'ingénierie.
Graham Miln
4

Voici ma supposition, en supposant que votre Mac possède un GPU intégré (par exemple, Intel Iris Graphics).

Lorsque vous avez ouvert votre thèse dans Aperçu, la mémoire de la carte graphique est utilisée pour contenir l’image ("texture") de la fenêtre d’aperçu, et peut-être aussi des pages de la thèse hors écran mais décodées.

Avec une carte graphique intégrée, la mémoire vidéo est en fait (partiellement?) Située dans la mémoire vive du système, qui est partagée entre le processeur et le processeur graphique. Sur certaines cartes graphiques intégrées, la quantité de RAM système utilisée est allouée de manière dynamique (voir Apple HT204349 ).

J'imagine que vous remarquez par intermittence un bogue dans le pilote de carte graphique et / ou dans Preview, qui ne libère pas correctement la mémoire système lorsque Preview recharge le PDF de votre thèse. (Cependant, ce bogue est atténué par OS X / le pilote libérant correctement la mémoire lorsque la prévisualisation se ferme.)

Vous pouvez essayer de regarder le résultat de kextstatet voir si les chiffres dans la Sizecolonne augmentent lorsque vous rencontrez le problème. Ma théorie est que l'augmentation de 8 Go dont vous avez parlé sera due au pilote de la carte graphique.

La commande suivante (à partir d'un commentaire sur cette réponse intéressante et liée ) trie la sortie de kextstatafin de voir plus facilement quel kext utilise le plus de mémoire (bien que notez ceci trie par Wiredcolonne ... il y a une incantation similaire, plus simple, dans cette répondez avec une explication si vous souhaitez modifier cela).

kextstat | awk 'NR==1{ printf "%10s %s\n", $5, $6; } NR!=1{ printf "%10d %s\n", $5, $6; }' | sort -n
Ashley
la source
Bonne supposition - et merci énormément pour cette sortie triée et utile de kextstat. Cependant, cela ne ressemble toujours pas à ce qui se passe réellement: au cours de l'aperçu, l'encombrement mémoire de com.apple.nvidia.driver.*est resté inchangé. J'ai modifié ma question pour refléter cela.
Landak