この記事の要点
- swap の増加とコンプレッサ負荷の上昇は、ユーザーから見えるタイムアウトより先に SLO 違反として扱う。尾部遅延が先に壊れる。
- Docker ビルド と フル iOS アーカイブ を無制限に同居させると最悪クラスの尖峰が再現される。時系列でずらすか Runner を分ける。
- CI コンテナには RSS 上限、ネイティブビルドには
-jの明示を。ノート向け既定は 7×24 ホストにそのまま移植しない。 - ピーク RSS とエージェントオーバーヘッドを プラン RAM から macOS 基底を引いた残り に収める。直列化できない尖峰向けに約 2〜4 GB のヘッドルームを見込む。
vm_stat を基準にしてください。1. 尖峰が積み上がる理由：コンパイラ、コンテナ、Xcode
ネイティブコンパイラはジョブ数をコア数に寄せると巨大な AST と並列コード生成領域を確保します。Docker Desktop や Colima 系は仮想化ページ、オーバーレイキャッシュに加え、パイプラインに amd64 イメージが紛れ込むと Rosetta 経由のヘルパで RAM を追加します。Xcode はモジュールグラフ、Swift explicit modules、索引や詳細ログが重なると CI がデスクトップ用途のスキームを継承したときにさらに膨らみます。
どれも「悪」ではなく、同一のユニファイドメモリへ同時に請求する負荷です。クラウド Runner ではリリース列車、夜間ジョブ、コンテナ統合試験を一台に詰めがちでパターンが増幅します。失敗形態は定常 OOM ではなく、数分続く swap 撹拌によって壁時計がジョブ上限を超え、ネットワーク不安定やシミュレータ固まりに見えることです。
コンテナ側のガードレールはメモリ上限とセットで効きます。マルチアーキの偶発膨張を抑えるイメージ選定は、Apple Silicon クラウド Mac で本番相当の Docker：arm64/amd64 イメージ、bind mount とビルドキャッシュのトラブルシュート手順（プランのリソース境界つき） とあわせて読むと整理しやすいです。
2. SSH のみでも回せる観測
三層で instrument します。ホスト積分、疑わしいプロセス、コンテナ予算です。ホストでは vm_stat で pageout とコンプレッサ統計をサンプリングし、対応する OS ビルドでは memory_pressure もソーク窗口で取得します。swap ファイル占有は generic な「使用中メモリ」グラフから切り離して追う価値があります。Apple Silicon は圧縮が攻撃的なので、swap の立ち上がりは遅行指標ですが「並列度の前提が破れた」決定的なサインになります。
Docker は代表パイプライン実行中に docker stats の RSS と limits を記録し、コンテナ内のコンパイル並列と上限を整合させます。そうしないと cgroup の throttle とホスト全体の swap の間でカーネルが振動します。Xcode 主体のレーンでは Derived Data 方針を切り替えながらピーク常駐をログに残してください。増分ビルドはディスク I/O を減らす一方、スキーム間で大きな RAM キャッシュを抱え続けることがあります。
ディスク逼迫はキャッシュ追い出し経由で RAM に間接圧力をかけます。inode と SSD の余裕は Apple Silicon クラウド Mac Runner：ディスクと inode のガバナンス——Derived Data、コンテナ、ログ に沿って確保し、メンテナンスがビルドとメモリ帯域を奪い合わないようにします。
# 軽量サンプル（CI 診断ユーザーで実行）
vm_stat | head -n 20
sysctl vm.swapusage
docker stats --no-stream 2>/dev/null || true3. テレメトリが黄信号のときの劣化プレイブック
重いレーンを直列化： RAM が限られたティアでは、計測で安全性が証明されるまで xcodebuild archive 全開とマルチサービス Docker ビルドを同時に置かない。
並列度クランプ： コンテナ同居時は Swift / clang のジョブ数を物理コア以下に下げ、sysctl hw.ncpu からエージェント予約を引いた決定的な -j に寄せる。
CI 行列の分割： UI 試験、バックエンド統合、パッケージングを一つの巨大グラフに詰めずキュー段階へ分割する。壁時計はわずかに伸びても尾部遅延は潰れやすい。
ネイティブ arm64 イメージを優先 し QEMU 肥大経路を剪定する。エミュレーションはメモリを増やし、見えないヘルプロセスを固定します。ビルドコンテキストを小さくし、BuildKit が RAM に巨大な中間層を抱え込まないようにする。
4. プラン RAM 境界とヘッドルームの算術
kvmboot の公開ティアは 16 GB ユニファイドメモリ とエントリー SSD、より大きな構成で 24 GB を軸にしています（詳細は プランとスペック）。macOS、ホスト CI で削れないデスクトップ系サービス、監視エージェント、SSH セッションでおおよそ 4〜6 GB を差し引き、Screen Sharing やリモート GUI デバッグが常時 on ならさらに約 1 GB を見込みます。
残りが 並列度予算 です。大規模 iOS アーカイブはリンク時に RSS が十数 GB 級へ伸びることがあり、それに中小の Docker サービスが二つ付くだけで 16 GB ティアは悪意なく枯渇します。24 GB はレーンの重なりを許すか、アーカイブ直列化を拒むチームでも swap マージンを読みやすくします。
キュー経済と尖峰は相互作用します。並列を増やすか RAM を広げるか Runner を増やすかは、OpenClaw 実行戦略と Runner プロファイル：リスク段階のルーティング、テナント枠とヒューマンゲート——クラウド Mac 算力を統制された実行面へ包む のような実行面の設計ともセットで検討すると筋が通ります。
5. 症状・想定原因・推奨アクション
| 症状 | 起きやすい根本原因 | 推奨アクション |
|---|---|---|
| ローカルでは通るが CI だけタイムアウトし CPU は低い | swap スラッシングまたはコンプレッサ停滞 | 並列度を下げる。swap を計測。Docker と Xcode の尖峰を時間でずらす |
| Docker ビルドが一度は成功するが同日後半に失敗 | デーモン RSS の累積とビルダリーク | ビルダ定期再起動。メモリ上限の強制。buildkit キャッシュの剪定 |
| 依存バンプ後に急に遅くなる | モジュールグラフ拡大・clang モジュール肥大 | オフラインでキャッシュ再構築。スキーム並列を抑制。RAM ティア見直し |
6. まとめ
Apple Silicon での swap は道徳的敗北ではなく スケジューリングの信号 です。コンパイラ・コンテナ・Xcode をユニファイドメモリ上の競合テナントとして扱い、ユーザーが怒る前に計測し、実際に購入した RAM ティアへピークを揃えましょう。理想のワークステーションではなく、契約した Runner に設計を合わせるのがコスト対効果が高いです。
クラウド Mac mini ではユニファイドメモリが CI の予測可能性を支える
Apple Silicon のメモリ帯域と高速な圧縮は、並列度を適正化すれば旧世代ノートより swap 痛みを和らげます。macOS は vm_stat や launchd、ネイティブ Xcode 経路まで含め Unix 系の観測が成熟しており、ベアメタル向け Runbook を専用クラウド Mac にほぼそのまま持ち込めます。テナント分離された専用ホストは過剰割当 SaaS で起きがちな隣人由来の RAM 膨張を避けやすく、待機電力の低さは夜間衛生エージェントの常駐にも向きます。Gatekeeper や SIP は CI スクリプトに紛れ込みがちな未署名ヘルパのリスクを狭め、手運用ミニラックを束ねるより総保有コストで有利になりやすい構図です。
Docker と Xcode の重なりを見越した 明示的 RAM ティアの Apple Silicon Runner が欲しい場合、kvmboot のクラウド Mac mini M4 は現実的な起点です——プランと料金を確認することで、swap をリリースフリーズ直前のサプライズではなく、意図したアラームにできます。