☰

为什么 launchd 会不断终止进程

tag-icon • tag-icon macos memory osx-mountain-lion launchd
为什么 launchd 会不断终止进程

我注意到我的 system.log 中充斥着如下消息：

May  5 12:56:08 macpro com.apple.launchd[1] (com.apple.qtkittrustedmoviesservice[8568]): Exited: Killed: 9
May  5 12:56:08 macpro kernel[0]: memorystatus_thread: idle exiting pid 8568 [qtkittrustedmovi]
May  5 12:56:11 macpro com.apple.launchd[1] (com.apple.audio.ComponentHelper[8564]): Exited: Killed: 9
May  5 12:56:11 macpro kernel[0]: memorystatus_thread: idle exiting pid 8564 [com.apple.audio.]
May  5 12:56:12 macpro com.apple.launchd[1] (com.apple.sleepservicesd[8572]): Exited: Killed: 9
May  5 12:56:12 macpro kernel[0]: memorystatus_thread: idle exiting pid 8572 [SleepServicesD]
May  5 12:56:12 macpro com.apple.launchd[1] (com.apple.audio.SandboxHelper[8563]): Exited: Killed: 9
May  5 12:56:12 macpro kernel[0]: memorystatus_thread: idle exiting pid 8563 [com.apple.audio.]

我知道当 RAM 已满时 launchd 可能会终止进程，但我认为我的 RAM 足够了（32GB）。我通常只有很少的可用内存，但当我检查活动监视器时，总是有超过 15GB 的“非活动”内存。这实际上不会造成任何问题，但我想清理一下我的日志文件，这样我就可以更轻松地发现真正的问题。

答案1

com.apple.launchd[1] (com.apple.audio.ComponentHelper[8564]): Exited: Killed: 9

此launchd报告称，它启动的一个进程（编号 8564，名为“com.apple.audio.ComponentHelper”）由于收到信号 9（SIGKILL）而意外退出。

原因实际上是由日志片段中的后续行（而不是前一行）指示的。

kernel[0]: memorystatus_thread: idle exiting pid 8564 [com.apple.audio.]

（似乎 syslog 只是处理和/或刷新了乱序的行。）杀手是内核本身。根据这（参见“MemoryStatus 和 Jetsam”标题下的第二段），在 OS X 中，内核的 memorystatus 线程会对低于某个阈值的可用内存做出反应，通过终止“标记为空闲退出”的进程。

因此，内核正在尽最后一搏，终止进程以避免耗尽可用 RAM。对于如此多的 RAM，我也会持怀疑态度，但这些日志条目似乎表明了这一点。请注意，“非活动”内存不是空闲的或“不再需要”的。非活动内存只是当前分配的内存中最近访问最少的内存。除非其内容已交换到磁盘，否则它不可重复使用。（我发现这解释非常有帮助。）您的交换文件是否已满？或者，我想知道如果分页器无法足够快地写入磁盘以跟上突然爆发的分配（和实际写入），是否会发生这种情况。

相关内容