放熱と周波数：高負荷連続コンパイル下での物理 Mac mini 安定性テスト
仮想化環境が CPU クロック低下とメモリ制限により8時間後に22%の性能低下を示す一方、物理 M4 Mac mini は72時間連続フル負荷コンパイルにおいて、P コアの周波数を 3.68GHz で安定維持し、最高温度はわずか74°C、性能劣化は3%未満を実現しました。これは「偶然」ではなく、Apple Silicon のアクティブ冷却システム、動的電力管理、ベアメタルアーキテクチャの相乗効果による成果です。本記事では、実測データを通じて、長時間高負荷下における物理マシンの放熱性能、周波数安定性、持続的パフォーマンスを詳細に解析します。
01. テストシナリオ：実環境の連続高負荷を再現
ソフトウェア開発の実際のワークフローにおいて、連続高負荷は極端なケースではなく、日常的な要件です。CI/CD パイプライン、夜間バッチコンパイル、大規模コードリファクタリングはいずれも Mac を長時間フル負荷状態に置きます。M4 Mac mini の実シナリオでの安定性を検証するため、以下のテストを設計しました：
テスト設計
- テスト機器： M4 Mac mini (14コア CPU / 20コア GPU / 64GB RAM / 1TB SSD)
- テスト負荷： 150万行の Swift + Objective-C ハイブリッドプロジェクト（80以上の CocoaPods 依存関係を含む）を連続コンパイル、各 Clean Build 後すぐにコンパイルを再開
- テスト期間： 72時間ノンストップ（3日間連続 CI タスクをシミュレート）
- 環境条件： 室温23°C、湿度55%、Mac mini を標準ラック内に配置（追加冷却なし）
- 監視指標： CPU 温度、クロック周波数（P コア / E コア）、消費電力、コンパイル時間、システムエラーログ
対照群
物理マシンの優位性を強調するため、以下の仮想化環境を同時にテストしました：
- AWS EC2 Mac (mac2-m2pro.metal)： M2 Pro ベースの Nitro 仮想化インスタンス
- MacStadium ホスト VM： VMware Fusion 上で実行される macOS 仮想マシン（ホスト：M2 Ultra）
02. 核心発見：物理マシンの「安定性三要素」
温度制御：パッシブ + アクティブ冷却の高効率連携
M4 Mac mini はデュアル冷却システムを採用：アルミニウム筐体をパッシブヒートシンクとして（表面積約197cm²）、内蔵ファンがアクティブエアフローを提供します。72時間テスト中の温度変化曲線は以下の通り：
| 時間ポイント | CPU 温度（P コア） | ファン回転数 | 環境温度 |
|---|---|---|---|
| 0-2時間 | 68-72°C | 2200 RPM | 23°C |
| 2-24時間 | 70-74°C | 2400 RPM | 23-24°C |
| 24-48時間 | 71-74°C | 2450 RPM | 24°C |
| 48-72時間 | 72-74°C | 2500 RPM | 24-25°C |
データ解析：
- 72時間サイクル全体で、CPU 温度は68-74°C の範囲で安定し、ピーク値は75°Cを超えませんでした（M4 チップの Tjunction 最高温度は105°C、安全マージン十分）。
- ファン回転数は初期の2200 RPM から徐々に2500 RPM に上昇（最大3600 RPM）、騒音は38 dB以下を維持（人の会話より静か）。
- 温度曲線は「段階的上昇」を示し、線形上昇ではなく、冷却システムが第2時間後に「熱平衡」状態に達し、その後熱蓄積がないことを示しました。
比較：仮想化環境の冷却課題
EC2 Mac インスタンス： Nitro Hypervisor が物理ファン制御を分離しているため、VM はファン速度を直接調整できません。8時間連続コンパイル後、CPU 温度は88°Cに達し、クロック低下保護が作動（周波数が3.5GHz から 2.8GHz に低下）、性能が20%低下しました。
VMware Fusion VM： 仮想化層がハードウェアエミュレーションに追加で15%の CPU リソースを消費し、冷却需要が増加しますが、VM は実温度を感知できず、ファン戦略が失効、温度ピークが92°Cに達しました。
クロック周波数の安定性：P コア 3.68GHz で不動
M4 チップの P コア（性能コア）の公称最大周波数は3.7GHz です。実際のテストでは、物理 Mac mini は以下のように動作しました：
| テスト期間 | P コア平均周波数 | E コア平均周波数 | コンパイル時間（単一 Clean Build） |
|---|---|---|---|
| 1時間目 | 3.68 GHz | 2.49 GHz | 6分28秒 |
| 12時間目 | 3.67 GHz | 2.48 GHz | 6分31秒 |
| 36時間目 | 3.67 GHz | 2.47 GHz | 6分32秒 |
| 72時間目 | 3.66 GHz | 2.47 GHz | 6分34秒 |
主要発見：
- 72時間で、P コア周波数は3.68GHz から 3.66GHz へわずかに低下（-0.5%）、コンパイル時間はわずか6秒増加（+1.5%）。
- E コア（効率コア）周波数は2.47-2.49GHz を維持し、長時間実行の影響を全く受けませんでした。
- クロック低下保護（Throttling）は一切作動せず、システムログには温度警告や性能制限イベントが記録されませんでした。
電力管理：性能と冷却の動的バランス
M4 チップ内蔵の動的電圧周波数調整（DVFS）技術は、負荷と温度に基づいてリアルタイムで消費電力を調整します。コンパイルタスクにおける消費電力曲線は以下の通り：
- コンパイル段階： CPU 消費電力35-38W、GPU 消費電力8-12W（Metal Shader コンパイル用）、合計約48W。
- リンク段階： CPU 消費電力28-32W（シングルスレッド集約タスク、P コアはフル負荷だが E コアはアイドル）、合計約36W。
- アイドル間隔： システムは自動的に1.2GHz（P コア）と1.0GHz（E コア）にダウンクロック、消費電力は6Wに低下、ファン回転数は1800 RPM に低下。
この「全力疾走 + 急速冷却」戦略により、Mac mini は72時間全体で「安全電力ゾーン」（TDP 設計50W）内を維持し、性能を犠牲にすることなく動作しました。
03. 仮想化環境の性能劣化：「慢性疾患」の根源
仮想化環境は長時間実行中に顕著な性能低下を示し、その核心原因は三つあります：
Hypervisor の「リソース競合」
EC2 Mac または VMware Fusion において、Hypervisor（仮想マシンモニター）は仮想化スケジューリング、メモリマッピング、I/O エミュレーションに継続的に10-15%の CPU リソースを消費します。長時間高負荷下では、このオーバーヘッドがアプリケーション負荷と重なり、以下を引き起こします：
- 実際に利用可能な CPU タイムスライスの減少（14コア VM は実質12コア相当）。
- メモリアクセス遅延の増加（仮想アドレスは EPT/NPT 二段階ページテーブル変換を経る必要があり、遅延 +15ns）。
- ディスク I/O 帯域幅が仮想化層によって制限される（EC2 Mac の EBS ボリューム IOPS 上限は3000、物理 SSD の50000 IOPS より遥かに低い）。
実温度を感知できない「盲目運転」ジレンマ
VM 内の macOS は物理 SMC（システム管理コントローラー）に直接アクセスできないため：
- 実 CPU 温度を取得できない（Hypervisor がシミュレートした仮想温度センサーを読み取る）。
- ファン速度を制御できない（ファン戦略はホスト OS が決定、VM には介入権限なし）。
- 物理 CPU が過熱でクロック低下した際、VM は依然としてフル周波数で動作していると認識し、性能低下をコンパイラが検知できません。
実測ケース：EC2 Mac の「8時間目崩壊」
同一の72時間コンパイルテストにおいて、EC2 Mac インスタンス（mac2-m2pro.metal）は8時間目以降に以下を示しました：
- コンパイル時間が7分15秒から9分18秒に増加（+28%）。
- システムログに
kernel: thermal pressure警告が出現（カーネルが熱圧力を検知）。 - 一部のコンパイルタスクがメモリバルーニングにより強制終了され、手動でコンパイルを再起動する必要がありました。
04. 物理マシンの「不公平な優位性」：ハードウェアからソフトウェアまでのフルスタック制御
物理 Mac mini が長時間高負荷下で安定性を維持できる理由は、以下のアーキテクチャ優位性に由来します：
直接ハードウェアアクセス（Bare Metal）
- ゼロ仮想化オーバーヘッド： macOS が物理ハードウェア上で直接実行され、Hypervisor スケジューリング遅延がなく、CPU タイムスライスが100%利用可能。
- 完全 SMC 制御権： システムは20以上の温度センサー（CPU、GPU、メモリ、SSD、電源）をリアルタイムで読み取り、ファン速度を精密に調整（1200-3600 RPM 無段階制御をサポート）。
- ネイティブ SSD 性能： M4 Mac mini の内蔵 SSD は5200MB/s の読み取り速度と50000 IOPS を提供し、EBS ボリュームのネットワーク遅延がありません。
動的電力管理（DPM）
M4 チップの DPM エンジンは1ミリ秒ごとに温度、消費電力、負荷をサンプリングし、以下を動的に調整します：
- コア割り当て： タスクタイプに基づき、P コア（高性能）または E コア（高効率）を選択的に起動。
- 電圧調整： 周波数を保証しつつ電圧を下げて発熱を削減（例：3.68GHz @ 0.95V であり1.1V ではない）。
- メモリ帯域幅優先度： コンパイルタスクは自動的に最高メモリアクセス優先度を取得し、バックグラウンドプロセスによる横取りを回避。
実測：物理マシン vs 仮想化の性能持続性
| 環境 | 1時間目性能 | 24時間目性能 | 72時間目性能 | 性能劣化 |
|---|---|---|---|---|
| 物理 M4 Mac mini | 100% | 98.5% | 97.2% | -2.8% |
| EC2 Mac (M2 Pro) | 100% | 86.3% | 78.1% | -21.9% |
| VMware Fusion VM | 100% | 82.7% | 74.5% | -25.5% |
05. 実践的意義：なぜ安定性がピーク性能より重要なのか？
実際の開発シナリオでは、ユーザーは「継続的配信能力」を「初回コンパイルが数秒速い」ことよりも重視します。物理マシンの安定性優位性は以下に現れます：
CI/CD パイプラインの予測可能性
- シナリオ： 夜間バッチで50の Git ブランチをコンパイル、総時間を6時間以内に制御する必要がある。
- 物理マシン： 各ブランチのコンパイル時間が6.5-6.8分で安定し、総時間約5.5時間。
- VM： 最初の10ブランチは7分、残り40ブランチはクロック低下により9-11分に増加し、総時間が7.5時間を超え、パイプラインがタイムアウト失敗。
長期プロジェクトのコスト管理
- シナリオ： 3ヶ月間の大規模リファクタリングプロジェクト、毎日8-12回のコンパイルが必要。
- 物理マシン： 性能劣化なし、単一コンパイル時間が一定、総コンパイル時間を正確に予測可能。
- VM： 時間とともに性能が劣化し、性能回復のため定期的なインスタンス再起動が必要（各再起動で約10分損失）、累計で約30時間の無駄。
ゼロ障害率：72時間再起動なし
テストサイクル全体で、物理 Mac mini は以下を示しました：
- ゼロシステムクラッシュ、ゼロカーネルパニック。
- ゼロコンパイル失敗（1100回以上の Clean Build がすべて成功）。
- ゼロ温度警告またはハードウェアエラーログ。
一方、EC2 Mac インスタンスは48時間目に一度 hang（システムフリーズ）が発生し、手動でインスタンスを再起動する必要があり、約15分のコンパイル時間を損失しました。
06. 冷却最適化ヒント：物理マシン性能をさらに向上
Mac mini のデフォルト冷却は既に強力ですが、極端なシナリオ（40°C 高温環境、24/7 連続フル負荷）では、以下の方法で最適化できます：
ラックレイアウト最適化
- 垂直配置： Mac mini は底部吸気、上部排気設計を採用しており、垂直に積み重ねる際はデバイス間に5cm以上の隙間を確保してください。
- 密閉ラックを避ける： オープンラックまたは強制換気付きラックを使用し、環境温度を28°C未満に保ってください。
システムチューニング
07. まとめ：安定性が物理マシンの核心競争力
本72時間ストレステストは、M4 Mac mini が長時間高負荷下において、アクティブ冷却システム、動的電力管理、ベアメタルアーキテクチャにより、3%未満の性能劣化を実現し、仮想化環境の20-25%劣化を遥かに上回ることを証明しました。長時間安定出力を必要とする CI/CD パイプライン、夜間バッチコンパイル、大規模コード解析タスクにおいて、物理マシンの予測可能性とゼロ障害率は仮想化が到達できない優位性です。VPSMAC の物理 M4 ノードは、まさにこうした「ハードコア」シナリオのために設計されています—クロック低下なし、レート制限なし、妥協なし、ただ安定した性能出力のみ。