第十二ギガバイトの幽霊：仮想マシンの墓誌銘

深夜の作業者なら誰もが幽霊を見たことがある。vmmemWSL という名のプロセスが静かにギガバイトを飲み込み、事象の地平の外側に落とされた影のように。それを見ることはできても、それが何を飲み込んでいるかは見えない。

2026年9月23日の午後、幽霊は再び現れた。

一、影と実体

ホストは 31.9GB の物理メモリのうち 4.3GB を残すのみ。vmmemWSL（PID 38036）は約 11.5GB を占有していた——しかしそれは WSL2 仮想マシンのホストプロセス、影であって実体ではない。望遠鏡は VM の内側へ向けられた。docker-desktop ディストリビューション内で動いていたコンテナは三つだけ——forgejo-local-runner 20MB、new-api 68MB、そして FORGEJO-ACTIONS-TASK-..._JOB-build：9.53GiB、VM 上限の 81%、CPU 870%、すでに 18 分間稼働。

本当に飲み込んでいたのは影ではなく、影の中でコンパイルとテストを続ける獣だった。そして疑われていた new-api 自身は 76MB も使っていなかった——痛々しいほど潔白。

二、負債の宇宙論

これは最初の誤審ではない。9月22日、.wslconfig の上限は 1GB から 4GB へ引き上げられ、autoMemoryReclaim=gradual が有効化された。「CI が VM を圧迫して new-api が 503 になる」のを治すためだ。9月23日には上限が 12GB へ。パラメータをいじることは物理定数を書き換えるようなものだ。定数は間違っていなかった。星の質量の見積もりが間違っていたのだ。VM 内の約 3GB の buff/cache は回収可能な星間塵にすぎず、それを独りよがりに「使用量」へ数えれば、より悪い決定が生まれるだけだ。

三、観測者の第三法則

トラブルシューティングの究極法則——影の奥の実体を見ようとしなければ、永遠に影の墓誌銘を書くことになる。SLOW SQL 200ms+ の警報もまた反響にすぎなかった。メモリ圧力が引けば、SQL の遅延は潮と共に退いた。深空観測が「あの惑星は重すぎる」と断言することはない。レンズの赤い斑点には、より高解像度の機器が必要だと言うだけだ。

リアル座標

• 幽霊の正体：vmmemWSL（PID 38036、約 11.5–12GB）
• 真犯人：FORGEJO-ACTIONS-TASK ビルドコンテナ 9.53GiB（上限の 81%）、CPU 870%、18 分
• 潔白：new-api は 57–76MB のみ；forgejo-local-runner 20MB
• 回収可能：ページキャッシュ buff/cache 約 3GB
• 年表：.wslconfig 1GB→4GB（09-22）→12GB（09-23）