只有在磁盘不够用的时候，才会去查一下。
很离谱，这个文件占据了 6.38GB 的空间，还是 DaisyDisk 帮我查出来的（上次帮我找出来 269.4GB 的垃圾文件）：
然后我就放 AI 去查到底发生了什么。
这个文件位于：
/private/var/db/powerlog/Library/PerfPowerTelemetry/BackgroundProcessing/CurrentBackgroundProcessingDB.BGSQL
它属于 macOS 自己的 PerfPowerTelemetry 系统，用来记录性能、功耗以及后台任务相关的遥测数据。
看谁在使用它：
sudo lsof \
/private/var/db/powerlog/Library/PerfPowerTelemetry/BackgroundProcessing/CurrentBackgroundProcessingDB.BGSQL
结果是：
COMMAND PID USER FD
dasd 395 root 7r
PerfPower 19463 root 12u
这里的 dasd 是 macOS 的后台任务调度服务，PerfPower 则负责性能和功耗数据记录。
也就是说，这个接近 6GB 的文件是 macOS 自己维护的后台任务遥测数据库。
继续查，找到了真正异常的任务：
com.apple.appstored.ArcadeResetPO
这是 Apple Arcade 有关的一个后台任务。
[!危险]但是，我没有订阅 Apple Arcade。
6GB 里到底装了什么？
这个 .BGSQL 数据库实际上可以直接使用 SQLite 查询。
sudo sqlite3 \
/private/var/db/powerlog/Library/PerfPowerTelemetry/BackgroundProcessing/CurrentBackgroundProcessingDB.BGSQL \
'.tables'
里面有几十张和后台任务有关的数据表：
BackgroundProcessing_TaskCheckpoint_24_5
BackgroundProcessing_TaskInstanceData_24_5
BackgroundProcessing_TaskMetadata_24_5
BackgroundProcessing_TaskBlockingPolicies_24_5
BackgroundProcessing_TaskThroughput_24_5
...
然后统计每张表实际占了多少空间
BackgroundProcessing_TaskCheckpoint_24_5 3516 MB
BackgroundProcessing_TaskInstanceData_24_5 2556 MB
其他表几乎可以忽略。
2253 万个任务，1.12 亿条状态记录
继续数一下到底有多少条：
SELECT COUNT(*)
FROM BackgroundProcessing_TaskInstanceData_24_5;
结果：
22,539,506
再数 TaskCheckpoint：
SELECT COUNT(*)
FROM BackgroundProcessing_TaskCheckpoint_24_5;
结果：
112,401,952
也就是说，这个系统数据库里有：
2253 万个后台任务实例
1.12 亿条任务状态记录
这显然不正常。
一个 TaskID，占了 99%
TaskInstanceData 里面有 ProcessName 和 TaskID。
先按进程统计：
SELECT
ProcessName,
COUNT(*) AS cnt
FROM BackgroundProcessing_TaskInstanceData_24_5
GROUP BY ProcessName
ORDER BY cnt DESC
LIMIT 30;
结果第一名有点奇怪：
ProcessName cnt
--------------------------- --------
22464148
contactsd 36525
spotlightknowledged.updater 6655
appstoreagent 4453
BiomeAgent 4400
...
超过 2246 万条记录，ProcessName 是空的。
既然进程名看不出来，就继续按 TaskID 查：
SELECT
TaskID,
ProcessName,
COUNT(*) AS cnt
FROM BackgroundProcessing_TaskInstanceData_24_5
GROUP BY TaskID, ProcessName
ORDER BY cnt DESC
LIMIT 30;
结果第一名非常夸张：
TaskID cnt
-------------------- --------
-6985415852000799361 22383668
一个 TaskID，就贡献了：
22,383,668
条记录。
占整个 TaskInstanceData 的大约 99%。
到这里基本已经可以确定：
问题就在这个任务。
顺着 TaskID，找到了 Apple Arcade
继续拿这个 TaskID 去查任务 Metadata：
TaskID:
-6985415852000799361
Name:
501:com.apple.appstored.ArcadeResetPO
终于出现了一个明确的名字：
com.apple.appstored.ArcadeResetPO
这是 App Store 体系里和 Apple Arcade 有关的后台任务。
但这里马上又出现了一个新问题：
[!问题]我根本没有用 Apple Arcade。！
继续查 App Store 的本地配置：
defaults read com.apple.appstored | grep -i -A2 -B2 Arcade
结果里面明确写着：
ArcadeSubscriptionState = Unsubscribed;
我真没订阅 Apple Arcade。
但与此同时，macOS 依然保存着：
ArcadeDeviceID
ArcadePayoutDeviceID
ArcadePayoutIntervalStartDate
ArcadePayoutResetDate
ArcadeSummaryIntervalStartDate
这些 Apple Arcade 相关状态。
两天，创建了 2238 万个任务
继续按日期统计这个 ArcadeResetPO：
SELECT
date(timestamp, "unixepoch", "localtime") AS day,
COUNT(*) AS cnt
FROM BackgroundProcessing_TaskInstanceData_24_5
WHERE TaskID = -6985415852000799361
GROUP BY day
ORDER BY day;
结果只有两天：
2026-09-20 10740336
2026-09-27 11643332
两次加起来：
22,383,668
更加巧合的是：
这两次正好相隔 7 天，都是周日
这已经很像一个周期性后台任务，在某个执行节点出现异常。
2238 万个任务，又留下了 1.12 亿条状态
接下来再看这些任务产生的 Checkpoint。
SELECT
CheckpointState,
COUNT(*) AS cnt
FROM BackgroundProcessing_TaskCheckpoint_24_5
WHERE TaskID = -6985415852000799361
GROUP BY CheckpointState
ORDER BY cnt DESC;
结果：
CheckpointState cnt
--------------- --------
15 22383701
10 22383701
16 22383700
30 22383658
20 22383637
42 4
45 1
前五种状态，每一种都是大约：
2238 万条
大约 2238 万个 ArcadeResetPO 任务实例，每个实例又留下了大约 5 个状态记录。
于是：
2238 万 × 5 ≈ 1.12 亿
这就是那个 6GB 数据库的来源。
其他人也遇到了同一个问题
查到：
com.apple.appstored.ArcadeResetPO
之后，我又找到了一个几乎一模一样的案例，对方最开始遇到的现象和我不太一样。
他是发现：
dasd
长期占用很高的 CPU。
但一路排查之后，最后同样找到了：
com.apple.appstored.ArcadeResetPO
对方进一步追踪发现，问题和一个字段有关：
ArcadePayoutResetDate
正常情况下，这个 Arcade 相关任务执行完成以后，下一次运行时间应该被推进到未来。
但出问题时，这个时间仍然停留在过去。
于是后台调度会形成类似这样的循环：
appstoreagent
↓
提交 ArcadeResetPO
↓
dasd 发现计划时间已经过去
↓
立即执行
↓
任务完成
↓
再次提交
↓
计划时间依然已经过去
↓
再次立即执行
如此反复、死循环。
如何解决
移动文件，重启。
BGDIR="/private/var/db/powerlog/Library/PerfPowerTelemetry/BackgroundProcessing"
BACKUP="$BGDIR/backup-$(date +%Y%m%d-%H%M%S)"
sudo mkdir -p "$BACKUP"
sudo mv "$BGDIR/CurrentBackgroundProcessingDB.BGSQL" \
"$BGDIR/CurrentBackgroundProcessingDB.BGSQL-wal" \
"$BGDIR/CurrentBackgroundProcessingDB.BGSQL-shm" \
"$BACKUP/"
sudo reboot
重启之后，没什么异常，查询文件也正常了：
-rw-r--r-- 1 root wheel 4.0K Sep 30 22:36 CurrentBackgroundProcessingDB.BGSQL
-rw-r--r-- 1 root wheel 32K Sep 30 22:36 CurrentBackgroundProcessingDB.BGSQL-shm
-rw-r--r-- 1 root wheel 2.4M Sep 30 22:38 CurrentBackgroundProcessingDB.BGSQL-wal
把备份文件删掉就好了
sudo rm -rf /private/var/db/powerlog/Library/PerfPowerTelemetry/BackgroundProcessing/backup-20260930-221535
最后，一顿删除猛于虎，一看空间多了6G
检查计划：
检查完成。你的电脑确认存在帖子中描述的同一个问题，证据链完整：
两点提醒：