Mac の CPU 負荷が高かった原因は fseventsd の肥大と cmux の登録ループだった

常時稼働している 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% まで下がりました。

当たり前だけど、まず「最近何が変わったか」を見るのが一番ありがちな近道でした。

まとめ

  • fseventsd が約 12GB まで肥大してスワップが暴れていたので、sudo killall fseventsd で再起動して解消
  • 更新後に未起動の cmux を lsd が 1 分に約 430 回登録していたので、一度起動して解消
  • 再発したら、fseventsd のメモリ(ps -axo rss,comm | grep fseventsd)と、lsd のログを見る
  • 自動更新されるアプリは、更新後に一度起動しておく

結果として load average は 1.6 まで下がりました。

今回の症状は、もしかすると私の環境だけかもしれません。

また数か月後に同じ経験をするかもしれないので、メモしておきます。