Windows 11 26H2（Build 26300.9550）環境において、WSL2（Windows Subsystem for Linux 2）の基本動作、メモリ管理機構、およびファイルシステムI/O性能のベンチマーク検証を実施しました。
1. 検証環境
- ホストOS / ゲストOS: Windows 11 Pro 26H2（OS ビルド 26300.9550）
- 仮想化基盤: VMware Workstation（Nested Virtualization 有効化）
- WSL2 ディストリビューション: Ubuntu（カーネル: WSL2 標準）
- 主要検証ツール:
- メモリ負荷測定:
stress-ng - I/O性能測定:
fio（Flexible I/O Tester） - プロセス・リソース監視: タスクマネージャー（
vmmemWSL）
- メモリ負荷測定:
2. メモリ管理検証：負荷追従と動的解放挙動
WSL2 初期バージョンで課題となっていた「Linux側で一度確保したメモリがWindowsホストへ即座に返却されない」問題に対し、26H2 上での挙動を確認しました。
検証内容
Ubuntu 上で stress-ng を実行し、一時的に 3GB のメモリ確保を行った後、コマンド終了に伴う Windows 側プロセス（vmmemWSL）のメモリ推移を観測しました。
Bash
stress-ng --vm 1 --vm-bytes 3G --timeout 30s --metrics-brief結果
- 負荷印加時:
vmmemWSLのメモリ使用量は約 4,005,524 KB（約 4GB） まで即座にスケールアップ。 - 負荷終了後: コマンド終了直後にメモリ解放が働き、約 992,948 KB（約 992MB） まで迅速に縮小・返却された。
ゲストLinux側のメモリ解放イベントに追従し、ハイパーバイザー連携による動的メモリ回収がスムーズに機能していることが確認できます。
3. I/O性能比較：Linuxネイティブ（ext4） vs Windowsマウント（/mnt/c）
WSL2 を運用する上で最大のボトルネックとなりやすいクロスファイルシステム（9P/Plan9 リダイレクター経由）と、仮想ディスク（ext4 / VHDX）ネイティブアクセスの性能差を fio を用いて計測しました。
測定条件
- シーケンシャルライト: ブロックサイズ 1MB、テストサイズ 1GB、direct=1
- 4K ランダムリード: ブロックサイズ 4KB、テストサイズ 1GB、numjobs=4、direct=1
ベンチマーク結果一覧
| 測定項目 | Linux ネイティブ (ext4 / ~) | Windows マウント (/mnt/c) | 性能差比率 |
| シーケンシャルライト スループット | 981 MiB/s（1,028 MB/s） | 77.3 MiB/s（81.1 MB/s） | ext4 が 約 12.7 倍高速 |
| シーケンシャルライト 所要時間 | 1,044 ms（約 1.0 秒） | 13,239 ms（約 13.2 秒） | /mnt/c は約 12.7 倍の所要時間 |
| 4K ランダムリード スループット | 46.5 MiB/s（48.7 MB/s） | 27.1 MiB/s（28.4 MB/s） | ext4 が 約 1.7 倍高速 |
| 4K ランダムリード IOPS | 11,900 IOPS（11.9k） | 6,941 IOPS | ext4 が 約 1.7 倍高速 |
| 4K ランダムリード 平均レイテンシ | 334.10 μs（約 0.33 ms） | 573.94 μs（約 0.57 ms） | /mnt/c の遅延が 約 1.7 倍 |
4. Windows Update の挙動確認
「セットアップ完了後、Windows Update を手動チェックしたところ、エラーでブロックされることなく『最新の状態です』と判定され、Defender のセキュリティ更新プログラム（KB2267602 等）およびマルウェア対策プラットフォーム更新（KB4052623）が正常に自動ダウンロード・適用されました。日常的なセキュリティパッチの受領についても、現時点では通常環境と遜色なく機能しています。」
5. 総括・考察
- メモリ返却の最適化: 急激な高負荷がかかった場合でも必要なフットプリントまで素早く拡張し、プロセス終了後は数秒でベースライン（1GB未満）までホストへメモリを返却する挙動が実証された。長時間の作業でもホスト側のメモリを圧迫し続けるリスクは大幅に低減されている。
- ストレージ配置のベストプラクティス:ランダムリードについては
/mnt/c経由でも 6,900 IOPS 超・サブミリ秒レイテンシ（約 0.57 ms）を維持しているものの、書き込み処理においては ext4 との間に依然として約 12 倍以上のスループット差が存在する。大量の小ファイル生成や頻繁な書き換えを伴うタスク（npm install、cargo build、コンテナビルドなど）は、引き続き Linux ネイティブ領域（~配下） にプロジェクトを配置して実行することが推奨される。
コメント