Windows Info 第403回

WSL Ver.2.0の新機能「自動メモリ回収」を実際に試す

　今回は、前回の記事（「プレビュー版が登場したWSLのVer.2.0　新機能を具体的に見る」）の続きで、Windows Subsystem for Linux（WSL） Ver.2.xの新機能である、自動メモリ回収機能を調べることにする。

　なお、前回WSLのVer.2.0を「WSL V2.0」と表記した。しかし、読者の方を少し混乱させてしまったようだ。そこで、最初に用語を少し整理させていただく。WSL2とWSL Ver.2.0の違いがわかる方は読み飛ばしていただいて構わない。

WSL関連の用語を整理

　WSLに限らず、ソフトウェア製品では、追加機能などを略称で表記することがある。WSLも登場以来さまざまな機能が追加されており、WSLという単語を含む用語が複数ある。

　この中でも「WSL2」とは、Linuxカーネルを使う仮想マシン環境でLinuxディストリビューションを実行するものだ。一方でそれ以前からあるWSLは、LinuxカーネルをWindowsカーネルなどでエミュレーションしており、ある程度の互換性を持っているものの、Linux特有の機能の一部を実行することができない。この環境は当初は単にWSLだったが、WSL2の登場によりWSL1と呼ばれるようになった。

　WSL2は、意味的にはWSLの第2世代ということなのだろうが、MicrosoftはこのWSL1とWSL2について「WSLバージョン」と呼んでいる（https://learn.microsoft.com/ja-jp/windows/wsl/about）。というのも、WSLがWindows 10のオプションコンポーネントとして提供されていた初期には、WSLにはバージョン表示機能がなく、Windowsのバージョンで区別されていたからだ。

　Windows 11の登場と同時に、WSLのMicrosoftストアで配布が開始され、ここでWindowsのバージョンとは同期しなくなった。その際にMicrosoftストアで配布されるWSLには、バージョンが付けられ、「wsl.exe -v」で表示できるようになった。

　同時にGitHubでもバイナリの配布が始まった。GitHubでのバージョン表示は、前記のコマンドで出てくるものである。強いて言えば、これはWSLのリリースバージョンである。現在たまたま「2.0.x」となっているだけで、WSL2とは直接は関係ない。

　なお、Microsoftでは、WSL Ver.2.0のことを「September 2023 update」と呼んでいる。しかし実際には、WSL Ver.2.0の新機能は、現時点でプレビュー状態であり安定版WSLでは利用できない。おそらく、WSL1／WSL2で「バージョン」という表記を使ってしまったため、WSL Ver.2.0.6などとは表記しにくいのであろう。

WSL Ver.2.0で新搭載された自動メモリ回収

　WSL V.2.0.0で搭載された自動メモリ回収（Automatic Memory Reclaim）は、Linuxのキャッシュメモリを解放する機能だ。Linuxカーネルは、空きメモリがあれば、積極的にファイルキャッシュなどに利用する。このため稼働中は、空きメモリがほとんどない状態となる。

　ただし、プログラム自体やプログラムが要求して利用するデータ領域などが必要になれば、解放可能なキャッシュを充当する。このため、Linuxの実行環境だけをみれば、空きメモリがないことは特に問題ではない。

　しかし、仮想環境としてみた場合、使っていないメモリを解放してホスト側で利用できれば、ホスト側での負荷が小さくなる。これまでもWSLには、仮想環境に対して動的にメモリ割り当てをし、空きメモリがあれば、これを解放する設定「pageReporting」が、WSL全体を設定する「.wslconfig」にあった。しかし、前述の理由により、WSLでファイルを多用すると、キャッシュが割り当てられてしまい、空きメモリが少なく、解放できるメモリが減ってしまう。

　今回の自動メモリ回収は、LinuxカーネルのControl Groups（Cgroups）という機能を使う。これは、プロセスのグループに対して、リソース割り当てを制御・隔離するための機能で、コンテナー技術などでの利用されている。

　Cgroupsには、2007年にカーネルに統合されたV1と、2016年にリリースされたV2がある。この2つには完全な互換性がなく、V1を前提に動作している場合に、必ずしもV2で動作させられるとは限らない。このため、多くのLinuxカーネルではV1とV2を併用している。

　なお、最新のWSL Ver.2.0.6では、新機能のうち「networkingMode」などいくつかが実験的機能ではなくなった。しかし、自動メモリ回収に関しては、まだ、実験的機能のままになっている。とはいえ、どの新機能もプレビュー版の機能であり、ある程度のリスクは残る。自動メモリ回収に関しては、Cgroups V1に依存するプログラムの互換性問題などが残り、まだどうなるのかが見えないので実験的機能のままなのであろう。

自動メモリ回収の実際

　ここでは「.wslconfig」を編集し、自動メモリ回収を動作させてみた結果を報告する。Beta Channelのプレビュー版Windows 11 Ver.23H2（OSビルド22635.2486）で、Ubuntu（22.04.3 LTS）を使って評価をしている。現行のWindows 11 Ver.22H2では、自動メモリ回収は正しく動作しないようである。

　まずは、自動メモリ回収を有効にしない、標準の状態を調べる。「.wslconfig」で「autoMemoryReclaim=disabled」を指定するか、もしくは何も設定しないと、自動メモリ回収は動作しない。

　Cgroupsの状態は、/etc/mtabで調べることができる。Ubuntu 22.04では、Cgroups V1（mtab内ではcgroup）とCgroups V2（同cgroup2）の両方が、/sysディレクトリにマウントされている。

自動メモリ回収を有効にしていないとき、/sysには、cgroup2（Cgroups V2）とcgroup（Cgroups V1）がマウントされている。また、/sys/fs/cgroupには、memory.reclaimが存在しない

　また、このとき、/sys/fs/cgroupディレクトリには、memory.reclaimは存在していない。なお、/sysは、カーネルの機能などを扱うための疑似ファイルシステムで、機能状態の取得・設定をファイルの読み書きでできる。

　キャッシュの状態は、freeコマンドで調べることが可能。「free -h」とすると、単位をつけて表示される。また、「free -h -s 300」とすると、300秒（5分）ごとに、コマンドを繰り返し実行する。

　ddコマンドを使い、ファイルの書き込みを行うとキャッシュが利用される。

ファイル書き込み前は、キャッシュ（buff/cache欄）は、324MBだったが、ddコマンドでファイルを書き込むと、851MBまで上昇する。その後5分間隔でメモリ状態を表示させても、キャッシュは変化しない

　直後のfreeコマンドでは、キャッシュ領域が大きくなっていることがわかる。その後、300秒ごとにfreeコマンドを実行しても、キャッシュ領域はほとんど変化していない（Linuxのシステムサービスなどでファイルを読み書きするため、多少の変動はある）。

　設定値を「gradual」とすると、Cgroups V1が禁止され、Cgroups V2のみが有効になる。これは、自動的に行われ、/sysにはCgroups V2（cgroup2）のみがマウントされる。また、/sys/fs/cgroup/memory.reclaimが有効になる。このファイルに回収させたいメモリ量を書き込むと、キャッシュメモリなど解放可能なメモリが空き状態になる。

自動メモリ回収を「autoMemoryReclaim=gradual」とすると、Cgroups V2（cgroup2）のみが/sysにマウントされるようになる。このとき、/sys/fs/cgroupには、memory.reclaimが存在するようになる。ファイルを書き込んだのち5分間隔でメモリ量を測定するとキャッシュが段階的に減っていく

　起動直後には、557MBだったが、ddコマンドでファイルを書き込むと1.1GBまでキャッシュが増えた。「gradual」では5分のアイドル時間が検出されると、段階的にキャッシュを減らしていく。5分単位でfreeコマンドを実行（free -h -s 300）していくと、キャッシュが段階的に減っていく。

　段階的に減らしていくのは、キャッシュが再び利用される可能性があること、Linuxでは遅延書き込みがあるため、時間が経過すると、解放可能なキャッシュ領域が増えるからだ。

　これに対して、設定値が「dropcache」の場合、Cgroups V1はそのままで、ディストリビューションの標準状態となる。このときには、Cgroups V2は使われず、/proc/sys/vm/drop_cachesなどが利用される。動作としては、5分のアイドル時間が検出されると解放可能なキャッシュをすべて解放する。

自動メモリ回収をdropcacheにすると、ファイルを書き込んだのち、5分間のアイドル時間が経過すると、キャッシュが大きく減少し、ほぼ初期状態に戻る

　「gradual」に比べると、少し乱暴な方法だが、Cgroups V1の動作を禁止しないというメリットがある。ディストリビューションのCgroupsの標準状態を変更しないため、Cgroups V1に依存するアプリケーションに影響を与えない。

　自動メモリ回収には、なかなか減りにくいWSLのメモリ利用量を下げる働きがある。実測してみると、確かに効果はあった。WSL側で大きなファイルを多数扱うため、Win32側への負荷が大きい場合に有効そうだ。