たぶんエンジニアには64GB(以上の)メモリのPCを与えた方が生産性が上がると思う件

会社で支給するPCのスペックについて、どういうものが良いのか、よく思案します。(僕は情シスではないのですが)
要は、エンジニアの生産性です。
最近はなんでもブラウザを利用するようになっていて、例えばクラウドを利用した開発や運用ならそのクラウドのWebページを複数開く必要があるし、システムによっては監視アプリケーションや運用に使うアプリや開発自体もWebでやる場合があると思います。

で、私のローカル環境について言うと、今使っているのは32GBメモリのPCなのですが、ブラウザって、タブごとに数十MB～数百MB(大体200～300MB, 大きいときは500MBなど)使ってて、ブラウザだけでめっちゃメモリ食うんですよね。

以下は、FirefoxでAWSの開発/ステージング/本番環境の検証や運用を1日やっていたときの、タスクマネージャでのfirefox.exeの各タブ(=プロセス)でのメモリ消費です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/620712/61b86fe6-b798-6ac8-a919-a780f2f0c333.png)

なお、僕の場合は、AWSで構築したアプリケーションのSEをやっていて、主なPCの使い方は以下となります

- ブラウザでAWSマネージメントコンソールを複数ページ開く
- ブラウザで調べものをするため複数ページを開く
- ブラウザでGitリポジトリや監視系のWebアプリやWikiを開く
- ブラウザでWeb会議, SaasのOfficeアプリ, メールアプリや社内サイトを開く
- wsl(メモリ割り当てはちょこちょこ調整していて、最近は4GBくらい)

それ以外では普通にエディタを数種常時開いているのと、たまにIDE(Eclipse, IntelliJ, SQL Developerなど)を開いています。他に、Slackのネイティブアプリ, ウィルス対策ソフト, エクスプローラ, cftmon.exe(IME関連)がそれぞれメモリを数百MB消費していますが、主にはブラウザがかなりメモリを消費している感じです。

そのような利用状況で、あるときWSLが突然反応しなくなりました。この状態には慣れていて、おそらくメモリ不足です。このときにタスクマネージャは以下のような感じでした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/620712/aaace7d3-ce6e-67ea-5cad-b216b9596ea1.png)
 
Windowsのメモリ不足かの判断は、コミット済みの左の数値を見ます。
私のPCはメモリが32GBのっていて、当初それは潤沢だと思っていたので、仮想メモリを無効にして利用しています。なので、物理メモリ = 仮想メモリとなります。仮想メモリは普通はOSデフォルトのままで良いと思うのですが(Windowsだと大体物理メモリの1.5倍程度を目安として、自動的に伸長されます。サーバではこの設定の方がコアダンプ生成に有効です。あとOOME防止が優先)、僕はインフラエンジニアで、メモリ使用量について自分でコントロールする気概だったのと、このPCを使う前のPCではもっと小さいメモリサイズのPCを使っていたので32GBあれば仮想メモリ不要かも感があったのと、仮想メモリを無効化することでSSDの寿命を延ばすメリットがあると思ったので、仮想メモリはOFFりました(wslでもswap使わない設定を入れてます)

で、普段逐一タスクマネージャでメモリ使用量を監視しながら使ってるのですが、やはりブラウザで調べものをするためにあれこれページを開いたり、AWSのサービスの検証や調査などでAWSサービスの複数ページを開いたりすると、メモリ使用量が25GB～32GB程度まで増えます。

現在、ブラウザでメモリ消費の少ないものは無いと思っていて、たくさんページを開くならどのブラウザを使ってもそれなりにメモリ消費が大きいと思っています(上述のとおり、タブごとに数百MBのメモリ消費をしていたりします)

また、Windowsのメモリ消費の見え方は要注意だと思っていて、タスクマネージャのプロセスタブで、各ブラウザが合計どのくらいメモリを消費しているか確認できたり、詳細タブで、各ブラウザの各タブ(それぞれブラウザと同じexe名)がどのくらいメモリを消費しているかを確認できるのですが(主にコミットサイズを見ます)、どちらも実際のメモリ消費より低い値が表示される傾向があります。これはタスクマネージャの詳細タブでコミットサイズ列を表示した上で、例えば適当なブラウザで、色んなWebサイトを30個とか開いて、タスクマネージャでのOS全体のコミットサイズ(パフォーマンスタブのコミット済みの左の値)とそのブラウザの各プロセスでのコミットサイズを確認後、ブラウザ自体落としてみて、落とした後のOS全体のコミットサイズを確認すると分かります。明らかに、各ブラウザでの各プロセス(各タブ)のコミットサイズの合計より、ブラウザを落としたあとのOS全体のコミットサイズの低下度合いは大きいです。

PCを数日上げっぱなしにして、複数ブラウザで多数のタブを開いた状態でメモリ使用量が高い状態になって、そのとき多数のタブを開いたブラウザを1個落とすと、コミットサイズが一気に7GBとか下がったりします。また、ブラウザ以外も含め全アプリを終了しても、OS全体のコミットサイズは20GB程度使用したままになっています。タスクマネージャの詳細タブでメモリを 500MB以上消費してるプロセスはないし、全プロセスのコミットサイズを合計しても10GBとかいきません。で、ためしにエクスプローラのプロセスを落としてみたりすると、タスクマネージャでのexplorer.exeのコミットサイズ以上にOS全体のコミットサイズが下がったりします。この辺がWindowsのメモリ管理の注意点かなと思っていて、実際にプロセスが使用しているコミットサイズは確認できないのでは??(プロセスごとのコミットサイズは当てにならない、本当はもっと使ってる)と思うところです(rammapとかで調査すると何かわかるかもですが..)。この不明なコミットサイズを解放するにはPC再起動なのですが、再起動すると各ページをいちから開き直さないといけないので面倒です。

で要するに何が言いたいかというと、最近はブラウザで何でもやるようになってきて、ブラウザはタブごとにメモリ使用量が大きいので、エンジニアの開発効率を上げてあげるには、メモリは最低限64GBくらいあった方が良いんじゃね、ってことです。
もちろん、システムによってはヒープダンプの解析(=アプリサーバのヒープと同じメモリ容量の空きが必要)や、他にもメモリ使用量の大きいIDEや解析ツールの利用があると思うので、一概ではないと思うのですが、普通にエンジニアにPCを与えるときに、64GB以上のメモリのPCを与えると、単純にブラウザをたくさん上げてるだけの使い方+αなら、メモリ不足とかスワッピングでのパフォーマンス低下や変な動作を気にせず開発/検証/運用ができると思うので、生産効率に寄与すると思います、という話となります。

ブラウザの使い方が、「必要なページだけ開いて、見たらすぐ閉じる、ブラウザ再起動も良く行う」のようなお行儀のよい?使い方をされているエンジニアならそんな潤沢なメモリ必要ないと思うのですが、クラウド使ってて複数環境を運用している(=環境ごとに設定を見比べたりするために複数タブを同時起動する)ような場合、32GBメモリのPCでは物理メモリの使用量を超過して仮想メモリ(スワップ領域)を利用していることもある(=たまになんかPC重かったり、特にそういう状態だとエクスプローラでの操作が反応しなくなったりしがち)ので、そういうのは大きいメモリのPCを配布しておくとそういう煩わしさから解放されるよ、で、32GBメモリはPC用には結構大きめに見えるけど、実はブラウザはタブごとに結構メモリ食うので、自分的には32GBでもあまり余裕がないなと思っていて、でも64GBあると結構余裕ありそうだな、と思う、という感じです。

ブラウザはメモリ消費が大きいということを認識してPCのメモリ決めないときついです。「特に重いソフト使ったりしないし大体ブラウザで用が済むからメモリは少なめのマシンで良いか」「重いソフトはIDEくらいで、他は大体ブラウザで済むからメモリは16GBで良いか」的な感じでメモリスペックの小さいPC買ってしまうと、ブラウザが10GB～20GBメモリを使ってるのに気づかず、仮想メモリに依存するようになって、「なんか夕方になるとPCが重いから再起動が必要なんだよね..」「vscodeのメニューバーの操作がなんかフリーズする」みたいに生産性が下がったり変な動作起きたりしがちです。というか、Windows10以降、OS起動したまっさらな状態で、メモリ7GBとかすでに使ってしまってるんですよね.. (以下は自分のPCの起動直後です。ウィルス対策ソフトとか、自分のPC固有のメモリ消費があると思うので、実際のWindowsの使用量は7GBくらいなのかなあと)

![20220720-1104-taskman_after_boot_clean.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/620712/e71c2dff-9232-8664-88e1-d52d083bbecf.png)