以前我曾被告知,某些应用程序存在内存泄漏的迹象是kernel_task
存在很大的内存占用,通常约为千兆字节。如果出了毛病kext
导致此内存使用量,我们期望看到分配的内存与预期分配的内存之间存在差异,即
diff <(kextstat|tr -s ' ' | cut -d ' ' -f 5) <(kextstat| tr -s ' ' | cut -d ' ' -f 6)
会返回“有线”和“名称”字样以外的内容。
在撰写论文时,我注意到在pdf在“预览”中打开时更改pdf常常会导致不好的事情发生:有时,的内存使用量kernel_task
可能会增加到大约8 GB,甚至更多。如果我取消预览,它会立即恢复正常。因此,显然出了点问题–在这种情况下,Preview正在泄漏内存。
所以,我的问题是这样的:如果我知道某个进程由于脚印的突然和意外增加而泄漏了ram kernel_task
,为什么OS X不能知道出了什么问题。如果杀预览恢复我的思念malloc()
“d内存,为什么不达尔文为我做垃圾回收自动的?
我对内存管理的工作原理有基本的误解吗?
编辑:(15/9/15)
这是我在说什么的演示。首先,我注意到内存使用率很高kernel_task
(注意:预览已打开,使用333 MiB的ram在活动监视器的底部可见):
遵循下面Ashley的有用评论,让我们找出每个kext使用了多少:
$ 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
$
因此,数量不多。我的机器同时具有离散GPU和集成GPU。他们的驱动程序仅使用少数MiB有线ram。凭我的直觉,让我们杀死Preview,看看下面的内存占用情况如何kernel_task
:
预览不见了,内核的内存占用大大减少了。仍然没有证据表明kext用法发生了变化:上述命令的输出未更改。
编辑:错误报告为22701036。我仍在等待苹果的回应。如果您在ActivityMonitor中检查过程,没有什么特别有趣的,但是也许我遗漏了一些东西。
kextstat
。我的理解是,如果KEXT泄漏,那么分配的字节和那些内核知道被分配会有所不同。在这种情况下,我将其放在此处以表明我没有泄漏的kext-因此,2)当Preview食用ram时不会发生这种情况。相反,kernel_task
增长很多。我将尝试重新创建此问题并拍照:-)。
diff
命令正在比较输出中的Size
和Wired
列kextstat
。我同意这Size
是“已分配的内存”,但我不认为它Wired
是“预期要分配的”(man kextstat
将其描述为“ kext占用的内核内存的有线字节数”)。2)您是否发现预览之间Size
和Wired
何时出现差异?