プログラミング

システムエンジニア回顧録｜メモリーはどこへ消えた？ Windows NTの調査帳

2000年のWindows NT調査メモを開き、メモリーの変化をどう記録し、原因の候補をどう絞ったかを振り返ります。鹿のメイザーが、パフォーマンスモニターとPrivate Bytesの読み方を語ります。

この回を動画で見る

同じテーマを、鹿のメイザーが図解と字幕付きで語ります。

鹿のメイザーの解説をYouTubeで見る

2000年のWindows NTメモ

どうも、鹿のメイザーです。今日は二千年十月の日付がある、Windows・エヌティー時代のメモリー調査メモを開きます。鹿なら足跡を追うところですが、ここで追うのは、時間とともに変わる数字です。残っているのは調査の手順や確認事項。そこから、当時どうやって容疑を絞ろうとしていたかをたどります。

メモリーが足りなくなったと聞くと、まず一番大きい数字を見たくなります。でも当時のメモは、パフォーマンスモニターでログを取り、時間がたつと数字がどう動くかを見るところから始まります。大きいかどうかと、増え続けるかどうかは、それぞれ別の問いなんですね。

手元のメモには説明と調査の項目が混ざっています。今回はその中から、システム全体を観測する方法、プロセスを絞る方法、再起動前後の証拠を残す意味を振り返ります。途中で出す例は、調査の考え方を説明するために組み立てたものです。

空きメモリーは入口

最初の手がかりは、システム全体で使える物理メモリーの変化です。ある時点で少ない、と分かったら、その前から減っていたのか、負荷がかかったときだけ減ったのかを知りたい。観測する時刻が一つしかないと、坂道を横から見る代わりに、足元の石を一つ眺めているようなものじゃ。

負荷が上がると一時的に減って、処理が落ち着くと戻ることもあります。キャッシュなどがメモリーを有効に使う場合もあります。空きが減ったという観測は調べる入口になりますが、何が減少を起こしたかを知るには、ほかの指標や操作時刻と並べる必要があります。

そこで、いつからいつまで、どの間隔で、何を記録したかを書いておきます。後日ログだけを渡されても、観測を始めた直後に何かを起動したのか、利用が落ち着いていたのか、その条件が分かると読みやすい。数字そのものにも、時刻と条件という名札が要るんですね。

プロセス別のPrivate Bytes

次にメモに出てくるのは、プロセスごとのプライベート・バイツです。マイクロソフトの資料では、ほかのプロセスと共有しない、そのプロセスに割り当てたメモリーの量として説明されています。システム全体で起きた変化と、個々のプロセスの変化を、同じ時刻で照らし合わせます。

ここで、物理メモリーに載っている量を見る指標と混同しないようにしたい。たとえばワーキングセットは、そのプロセスの仮想メモリーのうち物理メモリーにある部分を表します。数字の単位がどちらもバイトだとしても、何を数えているかが違えば、同じ意味では読めません。

候補が複数あるなら、名前だけで同じプロセスだと思わず、取得できる範囲で識別子や開始時刻も記録したいところです。再起動の前と後で同じ名前が出ていても、別の実行です。そこで線をいったん区切っておくと、増え方を比較するときの取り違えが減ります。

同じ操作を繰り返して比べる

想像上の例を二つ置いてみます。一つ目は、最初の処理でメモリーが増え、同じ処理を何度やってもだいたい同じ範囲に収まる場合。二つ目は、処理が終わった後の値が毎回少しずつ高くなる場合です。どちらも途中の一枚だけを見れば増加ですが、時間を並べると違いが出ます。

二つ目の形が見えたら、同じ作業を同じ規模で繰り返せているか、別作業が混ざっていないかを確かめます。負荷条件が変わってしまうと、数字の変化が操作の繰り返しによるものか、単に仕事量が増えたためか、ログから見分けにくくなるからです。

測り始めた直後には、初期化やデータの読み込みもあります。開始直後の上昇だけで判断せず、待機中の値、操作直後の値、しばらくたった値を同じ単位で追います。ここまで揃うと、どの条件を固定し、次に何を変えてみるかを、他の人とも相談しやすくなります。

再起動の前に観測を残す

元メモには、再起動という言葉も何度か出てきます。再起動はサービスを戻すために選ばれる場合があります。調査の目線では、そこで観測の条件が大きく切り替わる。再起動の前に何が起きて、後にどの値へ戻ったかを、同じログの上でも境目が分かるようにしておきたい。

たとえば、回復を優先したために前の値を保存できなかったなら、後の記録にその事情を書きます。後から取得した値を、再起動前も同じだったかのように埋めてしまうと、読み返す人が別の結論に向かいかねません。残っていないものは、空欄として明示する方が役に立ちます。

短い時間だけ状態が戻ったという結果も、その時点の回復としては大事です。その後も同じ操作や負荷で再び増えるかを見れば、回復の確認と原因の調査をつなげられます。元メモに再起動と書いてあることから、こちらで恒久対策の結果まで補うことはしません。

見えている範囲を確かめる

プロセス別に見ても、全体の変化を説明できる候補が見えないことがあります。そこで現在の資料では、カーネルのページプールや非ページプールを見る調査も紹介されています。ここは古い記録そのものの再現ではなく、どの範囲を見ていたかを考えるための、現在の補足です。

カーネル側のプールを調べる道具の一つがプールモンです。割り当てに付けられたタグごとの統計を並べられます。もしプールの使用量の増加が疑わしいなら、どのタグで時間とともに増えているかを調べる手がかりになります。数の大きいタグ一つで実装の不具合まで言い切る話ではありません。

調査の道具が変わっても、数字がどの範囲を表すかを最初に確かめるのは同じです。一つのグラフに答えを全部求めると、見えていないものに結論を出してしまう。どこを見たかと、どこが次の候補かを一行ずつ残しておくと、そこから続きを始めやすくなります。

ログに残す四つのこと

いま同じような調査メモを書くなら、観測の区間、何をしたか、どの対象のどの指標を見たか、そして結果の四つを揃えたいですね。グラフの画像だけより、元の数値と操作時刻があれば、もう一度別の尺度で見直せます。可能なら、増え方が見えなかった試行も残します。

増加が見えない結果にも意味があります。負荷が違ったのか、観測時間が短かったのか、同じ条件で試しても起きなかったのかで、その後の進み方は変わります。数字を取りに行く前に、どの仮説を区別したいかを決めておけば、あとで何をもう一度測るべきかを考えやすいんじゃ。

記録を公開するときは、実環境のコンピューター名、ユーザー名、接続先などは、調査の考え方を伝えるのに必要ありません。今回の動画では、調査の流れを描き直した図を使います。何を観測したいかを簡単に示せれば、読んだ人は自分の環境の名前に置き換えて考えられます。

後年の特集で観測を考える

関連して、技術評論社のソフトウェアデザイン、二千二十三年六月号には、オブザーバビリティ、つまり可観測性の特集があります。現代のクラウドやコンテナで何を観測し、その情報をどう行動につなげるかを扱っています。時代も対象も違うところを意識して、関連資料として紹介します。

古いメモで全体とプロセスを見比べたように、現代のシステムでも、どの範囲のデータをどう組み合わせるかが大事になります。一枚の折れ線に、利用者への影響や直前に変わった設定まで全部入っているわけではありません。分かりそうなところから順番に理由を絞る、という問いは残ります。

特集名を覚えて終わりにせず、観測した数字を使って次に何を判断するか、一つ考えてみると面白い。たとえば、この値が増え続けたら操作を止めて記録を残す、条件が違ったら次は揃えて測る、と事前に書いておく。データを取る理由が、後から見ても分かる形です。

調査の続きを渡す

今日は二千年の調査メモから、メモリーの数字をどう読むかを振り返りました。まず時間の流れの中で全体を見て、次にプロセスの指標を重ねる。増え続けるのか、あるところで落ち着くのかを、操作と時刻の記録を手がかりにして考えます。

メモリーはどこへ消えた、という題を付けましたが、最初に欲しいのは、消えた瞬間の目撃談より、増え方と条件が残った記録かもしれません。そこに何が分かったかと次に何を測るかが書いてあれば、別の人も、時間を置いた自分も、同じ地点から調査を続けられます。

みなさんの古い技術メモにも、使った道具や数値だけ残っているものがあるでしょうか。もし読み返すなら、その数字の名前と、どんな操作の後だったかを探してみてください。一行足すだけで、未来の自分が過去の調査を拾い直せることがあります。それでは、次の技術メモでお会いしましょう。

参考資料

-プログラミング