同一ホストでxcodebuild testを並べると、CPUより先にシミュレータRAMとブートI/Oが衝突しやすい。Test Planで縦割りし、ジョブ境界でランタイム系を分けると取り合いが減る。前提は
Mac CI リソースプール記事、境界設計は
Actions マルチランナー統合
参照。
1. Test Plan 分割とシミュレータの取り合い
単一Planは再実行が重く、細切りすぎるとブート回数でディスクが先に詰まる。近い所要のスイートを束ね、OSと画面サイズはPlan内で揃え、別ジョブは別ランタイム系へ。-maximum-parallel-testing-workersはRAMと同時ブート上限から逆算し、OOM手前で止める。
2. 高メモリノード vs worker 数
高RAM1台はキャッシュ再利用に強いが影響半径が広い。中RAM×複数workerは隔離は強いがキャッシュ効率は落ちやすい。Apple Siliconは統合メモリが支配的なので、同時N台の実測で圧が出る地点を決め、RAM増かホスト分割かを選ぶ。スワップが出た瞬間に全体が遅れる。
3. ディスク水位（DerivedData・ログ）
並行テストはDerivedDataでdfが跳ねやすい。-derivedDataPathをRUN_ID配下にし、終了時TTL掃引。空き20%未満で新規停止などしきい値をSLO化。ランタイム更新後はスナップショットを一度捨てる。
4. 比較FAQ（短答）
Q: worker だけ増やす？ A: RAM／ディスク不足だとフレーク増。Q: Plan細切り？ A: ブートI/Oが支配的なら統合。
5. ミニチェックリスト
- 同時台数・workers がRAM実測と整合しているか
- Plan がOS／デバイス族で過度に混在していないか
derivedDataPathとdfアラートがRUN単位か
テストを静かに回すなら専有メモリとmacOS
並行シミュレータは統合メモリが効き、共有だと隣ジョブのブートでI/Oが跳ねやすい。Mac mini M4は帯域と約4W級アイドルで据え置き向き。macOSはXcodeとシミュレータ同最適化とGatekeeper／SIPで説明しやすい。一台で十分な起点です。 Macstripe ホーム で専有ノードを確認し、今すぐ購入からどうぞ。
