その日は朝から頭痛がして、開発はほとんど進まなかった。頭が重いまま椅子に座って、画面を眺めていた時間のほうが長かったと思う。
夜になって、ようやく少し手が動くようになってきたところで、使っているAIエディタのCursorが落ちた。フリーズして固まるのではなく、画面がすっと消えてなくなる落ち方だった。
前日に「メモリ増設に6万円は払わない」と決めたばかりだったので、正直、決まりが悪かった。
前日に、64GBへのメモリ増設を保留したばかりだった
もともとCursorが重いという体感はずっとあって、その対策として32GBから64GBへのメモリ増設を検討していた。16GB×2を追加する構成まで決めて、商品も選び終えていた。
それを、最後の最後で保留にした。6万円払っても軽くならない可能性が残っていたからだ。
そのときの判断は、以前の記事に書いている。
その記事の最後で、私は「まずはお金をかけずに原因を切り分ける」と書いた。書いた翌日に落ちたわけだから、タイミングとしては最悪でもあり、都合が良くもあった。切り分けろと自分で書いた直後に、切り分けるべき材料が目の前に落ちてきたことになる。
「PCのメモリが足りない」と思い込んでいたが、数字を見ていなかった
落ちた直後に思ったのは、やっぱりメモリが足りないんじゃないか、ということだった。ブラウザを開き、Cursorで複数のチャットを動かし、裏ではDropboxの同期が走っている。32GBでは限界なのだろうと。
ただ、この時点で私が持っていたのは体感だけで、数字は何もなかった。
幸い、その日はProcess Explorerでプロセスの履歴を取っていた。深夜1時前から夜の10時半すぎまで、丸一日分のログが残っていた。それを読んでみることにした。
最初に思っていたのとは違ったのは、ログの見え方だった。私はブラウザのように「renderer」という名前のプロセスが並んでいるはずだと思っていたのだが、Windowsではそうなっておらず、ただCursor.exeという同じ名前のプロセスがいくつも並んでいるだけだった。どれが本体でどれが画面側なのか、名前からは判別できない。
結局、プロセスIDごとにメモリの推移を追う以外に方法がなかった。
こういう、思っていた形と実物が違うところから始まる切り分けは、前にもやったことがある。Windowsで勝手にフォーカスが外れる問題を追いかけたときも、原因の候補を1つずつ外していく作業だった。
1つのプロセスだけが、朝からずっと膨らみ続けていた
追いかけてみると、はっきりした形が出てきた。
犯人らしいプロセスは1つだけだった。朝から夕方にかけて、そのプロセスのメモリ使用量が、上下せずにひたすら増え続けていた。途中で解放される様子がまったくない。
いちばん大きくなったのは午後3時前で、約3,900MB。そして3.5GBを超えた状態が、午後2時すぎから5時前まで連続していた。その後、そのプロセスIDはログから消えている。落ちたか、私が再起動したかのどちらかで、時刻としては辻褄が合う。
さらに分かりやすかったのは、その後の数字だ。夜に立ち上げ直したあとのセッションでは、同じ作業をしていても最大700MB程度で収まっていた。
同じアプリ、同じPC、同じような作業内容で、3,900MBと700MB。差を作っていたのは環境ではなく、時間だったことになる。
RAMを増やしても直らなかったかもしれない
ここで引っかかったのは、PC全体のメモリはまだ余っていたということだ。
32GBのうち何割かは空いていた。それなのにCursorは落ちた。もしPC全体のメモリが枯渇していたのなら、他のアプリも巻き込んで動作がおかしくなるはずだが、そうはなっていない。落ちたのはCursorだけだった。
そこから今考えているのは、これはPCの容量の問題ではなく、1つのプロセスがそれ以上メモリを掴めない上限に当たっていたのではないか、という仮説だ。4GB近くで止まって、その少し先で落ちているように見える。
もしそうなら、6万円払って64GBにしても、同じ落ち方をしていた可能性がある。プロセス1つが使える量が変わらないなら、全体の器を大きくしても意味がない。
とはいえ、これも今の時点の仮説にすぎない。上限が本当にその値なのか、Cursor側の設定でどうにでもなる話なのかは、まだ確かめていない。1日分のログを1回読んだだけの話でもある。
ただ、少なくとも「重いからメモリを買う」という最初の発想は、根拠として弱かったと分かった。それが分かったのは収穫だった。
いま試しているのは、お金のかからない側の対策
数字を見て、増えていく原因として一番怪しいのは、1つのチャットを長く続けることだと思っている。膨らんでいたプロセスは、朝から夕方まで同じ作業を続けていた時間帯とぴったり重なっていた。
そこで、しばらくはこう使ってみることにした。
タスクが変わったら、チャットを継ぎ足さずに新しく開く。AIが出してきた差分は、あとで見るために放置せず、その場で採用するか捨てるかを決める。メモリが3GBを超えたあたりでCursorを再起動する。プロジェクト単位でフォルダを開き、デイリーノートを含む記録フォルダ全体を抱えたまま開発しない。
最後のひとつは、この時期に自分でやりにくくしてしまった部分でもある。ちょうど同じ日に、毎日の記録をつけているデイリーノートの編集担当を、Cursorへ戻したところだった。
デイリーノートも開発もCursorで扱えると楽なのだが、その分、1つのアプリに抱えさせるものが増えていく。便利さと重さは、たぶん同じところから来ている。
まだ分かっていないこと
何がメモリを増やしているのかは、まだ特定できていない。会話の履歴なのか、未処理の差分なのか、ファイルの索引なのか、切り分けられていない。
大きなファイルを索引の対象から外す設定も、まだ試していない。効果があるとしたら次に試すのはそこだと思っている。
それと、これは数字とは別の話なのだが、体調の悪い日に作業中のものが消えるのは、単純に効く。頭痛でほとんど進まなかった日の、やっと動き出した分が消えるのは、失った時間以上のダメージがあった。原因を調べる気になったのは、たぶんその悔しさのおかげだ。
原因が分かったから対策できる、という順番ではなく、悔しかったからログを開いた、というのが正直な順番だった。
長い処理をどう扱うかについては、以前も似たところでつまずいて、待ち方そのものを変えたことがある。
