zenet_logo

-株式会社ゼネット技術ブログ-

トップ > WSL > WSL利用中にPCが重くなる問題を調査したら、原因はVSCodeのファイル監視だった

WSL利用中にPCが重くなる問題を調査したら、原因はVSCodeのファイル監視だった

WSL トラブル対応 開発環境
VSCode監視でPCが重くなる？

はじめに

ゼネットの土屋です。

最近、開発中に不可解な現象が発生していました。

  • WSL を利用していると数時間後に PC が重くなる
  • Chrome が固まる
  • Excel まで巻き込まれて応答しなくなる
  • Windows 全体の動作が不安定になる

最初は Windows Update や WSL の不具合を疑いました。

しかし調査を進めると、意外なところに原因がありました。

今回はその調査過程と解決までの流れを紹介します。

発生していた事象

私の開発環境は以下のような構成です。

  • Windows 11 25H2
  • WSL2
  • VSCode Remote WSL
  • Ruby on Rails
  • Docker Compose
  • ESET

開発中は VSCode を利用して WSL に接続しています。

しかし数時間経過すると、

Chrome が固まる
↓
Excel が固まる
↓
Windows 全体が重くなる

という現象が発生していました。

特に不思議だったのは、

  • メモリは余っている
  • CPU 使用率も高くない

という点です。

そのため、

WSL が何か悪さをしているのでは？

と考えました。

まずは WSL を疑う

最初に確認したのは WSL の設定です。

[wsl2]
memory=8GB
swap=0

[experimental]
autoMemoryReclaim=gradual
sparseVhd=true

また WSL のバージョンも最新へ更新しました。

WSL 2.7.3
Kernel 6.6.114

しかし改善は見られませんでした。

メモリも CPU も余っている

タスクマネージャーを確認しても、

  • CPU は高くない
  • メモリも十分残っている

状態でした。

一方で気になったのがディスク使用率です。

症状が発生するとディスク使用率が急激に上昇し、PC 全体のレスポンスが悪化していました。

そこで、

何がディスク I/O を発生させているのか

を調べることにしました。

VSCode のプロセスを確認

WSL 上でプロセスを確認すると、VSCode が以下のプロセスを起動していました。

.vscode-server
 ├─ extensionHost
 ├─ fileWatcher
 └─ server-main

特に気になったのが fileWatcher です。

fileWatcher とは？

VSCode Remote WSL は、WSL 上でファイル変更を監視するためのプロセスを起動します。

この監視は、

  • ファイル検索
  • Git 状態表示
  • GitLens
  • コード補完
  • 問題表示
  • 自動リロード

など、多くの機能で利用されています。

つまり、

VSCode は開いているワークスペース配下のファイルを常に監視している

ということです。

プロジェクトのファイル数を調べてみる

そこでプロジェクトのファイル数を確認しました。

find . -type f | wc -l

結果は予想以上でした。

271,713

約 27 万ファイルです。

内訳を調べる

さらに調査すると、

vendor/bundle
144,741 ファイル

tmp
106,780 ファイル

となっていました。

つまり、

vendor/bundle + tmp

= 約25万ファイル

です。

全体の 9 割以上がこの 2 ディレクトリでした。

なぜこんなに増えていたのか

調べてみると、

vendor/bundle には大量の gem が配置されていました。

私は普段、Ruby や Rails の不具合調査や変更履歴の確認、OSS への Issue 報告やコントリビュートのために、さまざまなバージョンの gem をインストールして検証しています。

例えば、

  • Rails の不具合再現
  • Ruby のバージョン差異の確認
  • gem のリリースノート調査
  • OSS への報告用の再現環境構築

といった作業です。

そのため、検証用に追加した gem が vendor/bundle 配下に蓄積し、気付けば 14 万ファイルを超えていました。

また tmp についても、日々の開発や検証で生成されたキャッシュや一時ファイルが蓄積していました。

Rails アプリとしては正常に動作しており、これらのファイルが存在すること自体に問題はありません。

しかし VSCode から見ると、

監視対象ファイル
↓
25万ファイル超

という状態になっていました。

普段は意識していませんでしたが、VSCode のファイル監視という観点では、かなり厳しい環境になっていたようです。

推測される原因

今回の事象を整理すると、

VSCode Remote WSL 接続
        ↓
fileWatcher が大量ファイルを監視
        ↓
Git や拡張機能が定期的に走査
        ↓
ディスク I/O 増加
        ↓
ESET も追従してアクセス
        ↓
ディスクスパイク
        ↓
Chrome や Excel が巻き込まれて停止

という流れだったと考えています。

実際、Chrome や Excel が固まっていたためブラウザや Office の問題に見えていましたが、根本原因は別の場所にありました。

実施した対応

不要な gem を削除

まずは調査用 gem を整理しました。

結果として、

vendor/bundle

144,741
↓
41,671

まで削減できました。

VSCode の監視対象から除外

.vscode/settings.json

{
  "files.watcherExclude": {
    "**/vendor/bundle/**": true,
    "**/tmp/**": true,
    "**/.git/objects/**": true
  }
}

を設定しました。

結果

対応後は、

  • fileWatcher の CPU 使用率低下
  • VSCode の負荷低下
  • Windows 全体のフリーズ解消

を確認できました。

少なくとも現時点では再発していません。

まとめ

今回の件で学んだことは、

WSL が重いのではなく、その上で動くツールが大量のファイルを監視している可能性がある

ということです。

特に Rails 開発では、

  • vendor/bundle
  • tmp
  • node_modules

などが肥大化しやすいため、VSCode の監視対象になっていないか一度確認してみることをおすすめします。

私も最初は WSL や Windows Update を疑っていましたが、原因は意外と身近なところにありました。

もし「WSL を使っていると PC が重くなる」と感じている方は、一度ファイル数と VSCode の監視対象を確認してみてはいかがでしょうか。