結論：すぐに上限を下げず、3層に分けて確認する
タスクマネージャーでWSL2関連プロセスの使用量が大きくても、Dockerコンテナだけが原因とは限りません。 WSL2のLinux VMは複数のディストリビューションで共有され、アプリケーションの使用量だけでなくファイルキャッシュも含みます。
次の順で確認すると、必要な対策を選びやすくなります。
- Windows全体で本当にメモリ不足が起きているか確認する
- WSL2内のプロセス、キャッシュ、スワップを確認する
- コンテナごとの使用量を確認する
- WSLとDocker Desktopを更新する
- 必要な場合だけ
.wslconfigで上限を設定する - 同じ作業を再現し、改善と副作用を確認する
手順1：Windows全体の状態を確認する
タスクマネージャーの「パフォーマンス」からメモリを開き、使用中、利用可能、コミット済みを確認します。 次に「プロセス」でWSL2、Docker Desktop、IDE、ブラウザーなどを比較します。
WSL2関連だけを見て判断しないことが重要です。ブラウザー、IDE、言語サーバー、オンライン会議が大きく使っている場合、WSL2の上限を下げてもWindows全体の不足は解決しません。
PowerShellでは、WSLの状態とバージョンを次のコマンドで確認できます。
wsl --status
wsl --version
wsl --list --verbose古いWSLには既知の問題や挙動差があるため、更新可能な環境では更新後に再確認します。
wsl --update手順2：WSL2内の使用量を確認する
WSL2のシェルを開き、メモリとスワップを確認します。
free -h
ps -eo pid,comm,%mem,rss --sort=-rss | head -20| 確認項目 | 判断 |
|---|---|
available | WSL2内で新しい処理に利用できる見込みのメモリ |
Swap used | 重い処理中に増え続ける場合は割り当て不足の可能性がある |
buff/cache | 再利用可能なキャッシュをアプリの実使用量と混同しない |
| 上位プロセス | DB、Java、Node.jsなど、調整対象となる実プロセスを探す |
一度スワップされたデータが残っているだけの場合もあります。一時点の値ではなく、ビルドやテストを行いながら増減と操作感を確認してください。
手順3：コンテナごとの使用量を確認する
実行中のコンテナを1回測るには、次のコマンドを使います。
docker stats --no-stream \
--format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"特定のコンテナだけが大きい場合は、WSL2全体を制限する前に、そのサービスの設定を確認します。 Javaヒープ、データベースのバッファ、検索エンジン、開発時に不要なサービスなどが候補です。
コンテナ単位で暴走を防ぎたい場合は、Composeのメモリ設定やdocker run --memoryを検討します。
WSL2の上限はすべてのディストリビューションとDockerへ影響するため、問題の範囲より大きな制限になり得ます。
メモリがWindowsへ戻らない場合
新しいWSLには、使われなくなったキャッシュをWindowsへ戻す自動メモリ再利用の仕組みがあります。
Microsoftの現行資料ではautoMemoryReclaimにdisabled、gradual、dropCacheがあり、既定値も記載されています。
ただし、利用できる機能や既定値はWSLのバージョンで異なる可能性があるため、古い設定例をそのまま追加する前にwsl --versionと公式資料を確認します。
Docker DesktopのResource Saverは、WindowsのWSL2モードでは主にDocker Engineを一時停止してCPU使用量を抑えます。 Docker公式は、WSL2のメモリ削減には自動メモリ再利用を案内しています。Resource Saverだけでメモリが必ず減るとは考えないようにします。
原因確認のため一度だけWSL2 VMを完全停止する場合は、作業を保存してからPowerShellで実行します。
wsl --shutdownこれでメモリが戻っても、根本原因が解決したとは限りません。再び同じ作業を行い、どの操作で増えるかを確認します。
.wslconfigでメモリ上限を設定する
実測して上限が必要と判断したら、Windowsの%UserProfile%\.wslconfigを設定します。
このファイルは、WSL2で動くすべてのディストリビューションへ共通して適用されます。
[wsl2]
memory=12GB
swap=4GB
これは書式を示す例であり、32GB PCへの固定推奨値ではありません。Microsoftの現行資料では、memoryを指定しない場合の既定値はWindows搭載メモリの50％です。
Windows側のIDE、ブラウザー、会議アプリに必要な量を残し、WSL2側の最大負荷を満たす値を選びます。
保存後、作業中のWSL2環境を終了してから設定を反映します。
wsl --shutdownWSL2とDocker Desktopを再起動し、設定値と同じ負荷を再現して確認します。
free -h
docker stats --no-stream上限を小さくしすぎたときの症状
- ビルドやテストが以前より明確に遅くなる
- スワップ使用量とディスクアクセスが増え続ける
- コンテナが終了し、ログにメモリ不足が記録される
- IDEの言語サーバーやローカルDBが不安定になる
- 複数のWSL2ディストリビューションを同時に使えなくなる
症状が出た場合は上限を段階的に戻します。PC全体のメモリが不足しているのにWSL2へ小さな上限を付けると、Windows側の見かけの空きは増えても、開発作業の待ち時間が長くなる場合があります。
設定前後のチェックリスト
- Windows全体の利用可能メモリと操作感を確認した
- WSLとDocker Desktopのバージョンを記録した
free -hでavailableとスワップを確認したdocker statsで大きなコンテナを確認した- 通常作業と最大負荷時の数字を記録した
- 変更した設定値と理由を記録した
- 設定後に同じ負荷を再現し、速度と安定性を比較した
よくある質問
Resource Saverを有効にすればメモリも減りますか？
WindowsのWSL2モードでは、Resource Saverは主にCPU使用量を減らします。メモリが戻らない場合は、WSLの更新状況、自動メモリ再利用、実際のプロセス使用量を確認します。
32GBのPCではWSL2へ何GB割り当てればよいですか？
固定の正解はありません。Windows側に残す量と、WSL2内で同時起動するサービスの両方で決まります。まず既定状態で最大負荷を測り、必要な場合だけ少しずつ調整します。