PEANUT996

记一次 macOS appstoreagent 进程高 CPU 占用排查与解决

今天遇到了一个非常影响系统体验的问题，Mac 的风扇狂转，系统负载偏高。打开活动监视器（或终端执行 top 命令）一看，发现一个名为 appstoreagent 的进程长时间占用超过 100% 的 CPU。

这篇博客记录一下整个排查过程和最终的解决办法。

1. 发现问题

通过 top 命令查看到系统负载高达 7.83，其中 appstoreagent 进程（PID 42160）占用了 126.7% 的 CPU，并且已经累计消耗了将近 5 个小时的 CPU 时间。

top -l 1 -stats pid,command,cpu,mem,time -o cpu | head -30

输出显示：

42160  appstoreagent  126.7  ...  284:24.59

2. 深入排查

为了找到根本原因，我使用了几个系统自带的强大诊断工具。

进程采样 (sample)

首先使用 sample 命令对进程进行采样，看看它到底在忙什么：

sample 42160 3 -file /tmp/appstoreagent_sample.txt

分析采样结果，发现最热的线程是 Thread_969194 DispatchQueue_80: com.apple.appstored.ArcadeManager.dispatch (serial)。在 1145 次采样中，有 1102 次都在执行一个紧密的循环（Tight Loop），循环的主要模式是：

  1. semaphore_timedwait_trap (等待信号量超时)
  2. 调用 +[AMSDevice macAddress] 和 IOKit 去查询网卡的 MAC 地址

查看系统日志 (log show)

然后通过 log show 查看该进程最近的系统日志：

log show --predicate 'process == "appstoreagent"' --last 30m --style compact

日志暴露了两个致命错误：

  1. 数据库结构不匹配 (SQLite Error): no such column: active_launch_events.recent_launch_times 这说明 AppStoreDaemon 框架试图查询 Biome 数据库时，因为找不到某一列而报错。这通常发生在 macOS Beta 版（我当前使用的是 macOS 27.0 Developer Beta）中，数据库 schema 发生了变化，但代码没有同步更新。
  2. 后台任务调度失败: updateTaskRequest called for an already running/updated task com.apple.appstored.ArcadePostPO

3. 根因分析

经过排查，结论很明确：这是 macOS 27.0 Developer Beta 的一个系统 Bug。

appstoreagent 的 ArcadeManager 组件在尝试执行数据同步时，由于底层的 SQLite 数据库字段不匹配和后台任务重调度失败，导致整个同步流程陷入了死循环。在这个死循环里，它不断地设置极短的超时时间等待信号量，并在每次超时后去查询一次网卡 MAC 地址，从而把一个甚至多个 CPU 核心完全跑满。

4. 解决办法

既然是系统的 Bug，在 Apple 推出下一次 Beta 更新修复之前，我们需要一些临时的缓解措施。

尝试 1：直接 Kill 进程

最直接的想法是杀掉这个进程：

kill 42160

结果：失败。 杀掉之后，launchd 会立刻把它重新拉起来，新的进程依然会 100%+ 占用 CPU。

尝试 2：清理缓存

怀疑是本地缓存或数据库损坏，于是清理了相关缓存目录：

rm -rf ~/Library/Caches/com.apple.appstoreagent/*
rm -rf ~/Library/Caches/com.apple.AppleMediaServices/Metrics/com.apple.appstored/*

结果：无效。 因为根本原因是代码和系统数据库 schema 的不兼容，不是缓存损坏。

尝试 3：通过 launchctl 禁用服务

既然不能让它自动重启，尝试从 launchd 层面彻底禁用这个守护进程：

# 1. 禁用该服务
launchctl disable gui/$(id -u)/com.apple.appstoreagent

# 2. 强制终止当前正在运行的进程 (假设 PID 为 75762)
kill -9 75762

结果：依然失败。 虽然禁用了服务，但 appstoreagent 是一个 XPC Mach Service。如果有其他进程（比如 App Store 或者系统后台组件）向它发送了 XPC 消息，launchd 依然会无视 disable 状态，将其按需唤醒 (On-Demand Launch)。唤醒后它又开始 100%+ CPU 狂飙。

最终方案：使用 STOP 信号冻结进程 (终极必杀)

由于它受 SIP (系统完整性保护) 保护，我们无法删除它的 plist 文件，也无法阻止 XPC 唤醒它。 但是，我们可以利用 Unix 的进程状态控制，给它发送一个 STOP 信号。

# 找到 appstoreagent 的 PID (例如 76759)，发送 STOP 信号
kill -STOP 76759

原理解析： 发送 STOP 信号后，进程的状态会变成 T (Suspended/Stopped)。此时，操作系统内核会完全停止调度该进程，它的 CPU 占用率会瞬间掉到 0%。 最精妙的地方在于：进程并没有退出。因为它依然“活着”并且依然绑定着对应的 XPC 端口，launchd 就不会认为它挂了，自然也不会去启动新的实例。任何发给它的 XPC 消息只会排队等待或超时，完美规避了死循环和无限重启。

执行完以上操作后，世界终于清静了。系统负载迅速下降，CPU Idle 恢复到正常水平。

冻结后的副作用

appstoreagent 主要负责 App Store 应用的后台更新、下载安装、Arcade 同步和许可证验证等。冻结后：

  • App Store 应用将无法自动更新，也不能下载新应用（如果需要下载应用，请使用 kill -CONT <PID> 恢复它，或者直接 kill -9 让它重启，趁它没陷入死循环前赶紧下载）。
  • 系统的核心功能和其他非 App Store 安装的应用不受任何影响。

总结

遇到 macOS 系统进程高占用问题时，top + sample + log show 是非常强大的排查三剑客。对于这种由于 Beta 版系统 Bug 导致的死循环问题，并且进程受到 SIP 保护被 XPC 频繁唤醒时，利用 kill -STOP 将进程冻结，是目前最优雅、最有效的保命手段。