3
常時稼働している Mac の負荷が、ここ最近ずっと高い状態でした。
最大で load average が 47 まで上がり、操作がもたつくこともありました。
原因を調べるのに Claude Code に手伝ってもらいながら、結局 2 つの原因にたどり着いたので、メモしておきます。
症状
- macOS Sequoia 15.7.7、約 94 日間連続稼働
- load average は 47、CPU は sys が 82%、idle が 2.7%
- 空きメモリは 31MB まで減っていて、スワップが 10GB / 11GB 使われていた
- user ではなく sys が高いので、アプリの計算ではなくカーネル側の処理が重い状態
まず試したこと
最初に怪しいと思ったのは、メモリを 9.8GB も使っていた OrbStack でした。
コンテナ（Dify や Pi-hole）を動かしているので、いかにも重そうです。
なので OrbStack を再起動してみました。
でも、負荷はまったく下がりませんでした。
むしろ再起動直後は load average が 18 から 47 に悪化して、ここで数時間を無駄にした気分です。
調べたこと
top を見ると、kernel_task と fseventsd が上位に並んでいました。
fseventsd は CPU が 50〜78% で、メモリ使用量は約 12GB もありました。
次に fs_usage でファイルアクセスを見たところ、大半が PAGE_OUT_ANON と swapfile への書き込みでした。
つまり、どこかのアプリがファイルを大量に書いているのではなく、メモリ不足でスワップが暴れている状態でした。
top と fs_usage の抜粋
Load Avg: 47.40, 22.06, 12.50
CPU usage: 15.27% user, 81.97% sys, 2.74% idle
PhysMem: 32G used, 31M unused
PID COMMAND %CPU
89 fseventsd 61.4 (RSS 約 12GB)
0 kernel_task 108.6
PAGE_OUT_ANON B=0x40000
PgOut[AT2P] B=0x40000 /dev/disk3s6 /System/Volumes/VM/swapfile10
原因1: fseventsd のメモリ肥大
fseventsd はファイルシステムの変更イベントを扱う macOS のデーモンです。
これが約 12GB まで膨らんで、物理メモリを食いつぶしていました。
長期間連続稼働していたことで、どこかに溜まっていったのかもしれません（原因までは特定できていません）。
sudo killall fseventsd で再起動したところ、メモリは 7MB、load average は 2.3 まで下がりました。
その後 2 時間、5 分おきに記録しても、fseventsd は 8MB のまま増えませんでした。
原因2: 更新後に未起動の cmux を lsd が登録し続けていた
fseventsd を直した後も、lsd が 60%、syspolicyd が 35〜68% と高いままでした。
log show で lsd のログを見ると、1 分間に約 430 回、com.cmuxterm.app の登録処理（Building bundle record）が繰り返されていました。
cmux は Homebrew の cask で入れているターミナルで、前日に自動更新（Sparkle）が入っていました。
その後、一度も起動していませんでした。
アプリ自体は壊れておらず、codesign の検証も spctl の判定も問題ありませんでした。
効かなかった対処
-
lsregister -f -R -trustedで再登録 → 変わらず -
brew reinstall --cask cmux→ 再インストール直後に再発 - xattr で com.apple.quarantine を削除 → 変わらず
- /Applications から退避してみると、lsd と syspolicyd は 0% に下がった（原因が cmux だと確定）
結論
cmux を一度起動したら、登録の繰り返しがぴたっと止まりました。
理由は正直よく分かりませんが、更新後の初回起動が済んでいなかったせいではないかと想像しています。
終了した後も再発はなく、lsd は 0.4%、syspolicyd は 0.5% まで下がりました。
当たり前だけど、まず「最近何が変わったか」を見るのが一番ありがちな近道でした。
追記: mediaanalysisd と mds_stores も重かった
後日、別のタイミングでも CPU 負荷が高くなったので、追記しておきます。
今度は mediaanalysisd が CPU を 60〜78% 使い続けていました。
mediaanalysisd は「写真」アプリのライブラリ（約 108GB）を、顔認識やシーン認識のためにバックグラウンドで解析するデーモンです。
起動から 6 日以上動き続けていて、累積 CPU 時間は約 66 時間でした。
さらに Spotlight の mds_stores も 47% 前後で、同時に高くなっていました。
対処は次の通りです。
-
killall mediaanalysisdと通常のkillでは止まらず、kill -9で停止 - 解析キャッシュ（
~/Library/Containers/com.apple.mediaanalysisd/Data/Library/Caches、約 95MB）を削除 - Spotlight は使っていないので、
sudo mdutil -a -i offでインデックスを停止
数分後に確認したところ、mediaanalysisd は再起動しておらず、mds_stores も 0% まで下がっていました。
mds_stores が下がったのは、mediaanalysisd を止めたからなのか、Spotlight を止めたからなのか、切り分けられていません。
また、mediaanalysisd が止まらなくなった根本的な原因（ライブラリの解析が終わらない理由）は分かっていません。
再発したら、「写真」アプリを開いたまま様子を見るか、ライブラリの修復を試すつもりです。
まとめ
- fseventsd が約 12GB まで肥大してスワップが暴れていたので、sudo killall fseventsd で再起動して解消
- 更新後に未起動の cmux を lsd が 1 分に約 430 回登録していたので、一度起動して解消
- 再発したら、fseventsd のメモリ（ps -axo rss,comm | grep fseventsd）と、lsd のログを見る
- 自動更新されるアプリは、更新後に一度起動しておく
- mediaanalysisd が居座ったら、
kill -9で止めてキャッシュを削除。Spotlight を使わないなら mdutil で止める
結果として load average は 1.6 まで下がりました。
今回の症状は、もしかすると私の環境だけかもしれません。
また数か月後に同じ経験をするかもしれないので、メモしておきます。