コグノスケ

WindowsとLinuxのメモリ割り当て戦略の違い

目次: Linux
目次: Windows

新年早々、WindowsとLinuxのメモリ割り当て戦略の基本的な違いをすっかり忘れていて、ひどい目に合いました。

症状としてはSteamでゲームをしてると頻繁にゲームが落ちたり、ブラウザがクラッシュします。

何を調べた？

疑った順に、

AMDのグラフィクスドライバ？

• バージョンアップしてもダメ。
• クロックダウンしてもダメ。
• 無効化し（Intel内蔵グラフィクスに切り替え）てもダメ。

熱暴走？

• Intel内蔵グラフィクス切り替え＋CPUクロックダウンで熱を抑えて、50℃行ってないのにダメ。

メモリ不足？

• 物理メモリは数GB余っているのにダメ。

結論は？

仮想メモリの枯渇でした。Windowsは仮想メモリを物理メモリ＋ページングファイルの合計量までしか割り当てません。私の環境は物理メモリ16GB＋ページングファイル1GBに切り詰めていたため、仮想メモリは17GBまでしか確保できません。

ゲーム＋ブラウザを起動すると仮想メモリの消費量が17GBを超えるときがあります。仮想メモリの割り当て量が上限ギリギリに達して、ゲームもしくはブラウザの運が悪い方が、仮想メモリを要求すると、割り当てに失敗します。

するとNULLポインタが返り、NULLポインタにアクセスしてゲームorブラウザがクラッシュしてしまうようです。誰一人として、仮想メモリの割り当て失敗を想定せんの？誰か1人くらいVirtualAlloc() が失敗したって教えてくれても良いのに……。

対策は？

ページングファイルを適当に増やせば（とりあえず16GBくらいにした）安定しました。

なぜそう判断した？

気づいたきっかけはゲーム（Cities: Skylines）のクラッシュダンプです。

クラッシュダンプのエラーログ

エラーログを見るとpaging fileの空きが1MBしかありません。Windowsではこれは仮想メモリの空きを表すそうです。これを知らなかったがために、全然関係ないドライバとか熱暴走を疑い、遠回りしてしまいました。

確認方法は？

タスクマネージャーで「コミット済み」の値をチェックすると、仮想メモリの使用量がわかります。これがゲーム＋ブラウザで17GBを超えていました。

タスクマネージャー「コミット済み」の例

ダメ押しで、下記のようなVirtualAlloc() APIを呼んで仮想アドレスを大量にガメる（物理メモリはほぼ消費しない）プログラムを書いて、わざと仮想メモリだけを枯渇させました。

#include <cstdio>
#include <cstdlib>
#include <windows.h>

#define CNT    16

int main()
{
	const size_t s = 1024 * 1024 * 1024;
	char buf[1024], *pb;
	void *p[CNT];

	for (int c = 0; c < CNT; c++) {
		p[c] = VirtualAlloc(NULL, s, MEM_COMMIT, PAGE_READWRITE);

		FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM, NULL, GetLastError(), 0, buf, sizeof(buf) - 1, NULL);
		printf("%s\n", buf);

		pb = (char*)p[c];
		for (size_t i = 0; i < s / 8192; i++)
			pb[i] = (char)i;
	}

	for (int c = 0; c < CNT; c++)
		VirtualFree(p[c], s, MEM_DECOMMIT);

	return 0;
}

この状態でゲームを動かすと容易に同じクラッシュが起こせます。というわけで仮想メモリの枯渇で確定と判断しました。

反省点は？

WindowsとLinuxの仮想メモリ割り当て戦略は全く違うのに、同じノリでWindowsのページングファイルを削ってしまったことですね……。一応、違いは知っていたんですが、行動に活かせず思い切りハマりました。

補足

Windowsは仮想メモリ割当てが保守的です。仮想メモリの割り当て上限＝物理メモリ＋ページファイルの合計となります。

• 利点: 全プロセスが仮想メモリ全域にアクセスしても、物理メモリ＋スワップで対応できます。仮想メモリと物理メモリの対応は必ずできて、プロセスをKillする必要は原理的に発生しません。
• 欠点: 仮想メモリを確保だけしてアクセスしないプロセスが大量にいると、仮想メモリが先に枯渇します。物理メモリは遊んだままで無駄になります。

Linuxは仮想メモリの割り当て上限＞物理メモリ＋スワップファイルの合計となります（over commitment）。

• 利点: 仮想メモリを無駄に確保するやつがいても、物理メモリ＋スワップを使い切れます。
• 欠点: 全プロセスが仮想メモリにアクセスしてしまうと、仮想メモリに紐づける物理メモリorスワップ領域が不足し、メモリ使用量を減らすためプロセスをKillせざるを得なくなります。

WindowsとLinuxのメモリ割り当て戦略は、利点と欠点が逆になるだけで、どっちもどっちです。

まとめ

今回の教訓をおさらいすると、Windowsを使っているのに、Linuxと同じノリでページファイルを1GBとか小さいサイズに削ると、速攻で仮想メモリが枯渇してひどい目に合うんでやめようね！ってことです。

デザイン変更

記事以外の表示（リンクとか編集ボタンとか）が縦に並んでいて、横長のディスプレイで見たときに邪魔なので、ちょっとだけデザインを変えて縦方向の長さを詰めました。

デザインはあまり詳しくないですが、もっと文字が読みやすくなるようにするにはどうしたら良いんでしょうね……？

ANAのチケット代の仕組み

年末の帰省チケットを解約したとき（2020年12月17日の日記参照）に価格が激変していたことが気になったので、年末年始の羽田→千歳便の各チケットの価格をプロットしてみました。

年末年始の羽田→千歳便チケット価格

どうやらチケットの種類に関係なく、最後に付いているアルファベットで価格帯が決まるようです。Aが一番高くて、B, C, D, ... と安くなっていくようです。10月に予約したSUPER VALUE 75 Hが、今日予約できるVALUE 3 Jより高くなるのはこれが理由でした。

ANAの予約システムは、遠い予約日（1/Mくらい）だと、空席予測を強気に出すのかやや割高の運賃設定をしています。

• VALUE 3 H（21360円〜）
• VALUE 1 F（27560円〜）

くらいかな？早朝便、深夜便などは1ランク安くなりがちです。しかし、搭乗日が近づいて（増発を決めてしまった12/30など）、誰も乗らないことに気づき始めると、未だかつて見たことない安さのチケットが出現します。

• VALUE 3 K（13560円〜）
• VALUE 1 G（26260円〜）

こんな感じですね。安いなあ。

現在は特殊な状況に置かれている

遠い予約日が強気の価格になるのは、SUPER VALUEでも傾向が一緒のようです。SUPER VALUEの予約日は最短でも21日後と、必然的に遠くなるため、COVID-19の状況下ですと、予約日が遠いSUPER VALUEの方がかえって割高で買ってしまう可能性が高いです。

例えば、一番近いSUPER VALUEの予約日は21日後の1/10です。ラインナップはVALUE 3 H, VALUE 1 G, SUPER VALUE 21 J辺りで、今この瞬間はSUPER VALUE 21 Jが一番安く見えますが、1/10はおそらく誰も乗りません（帰省ラッシュがない以上、Uターンラッシュも起きない）から、1/3くらいまで待てば、VALUE 3 Kとかが登場して、SUPER VALUE 21 Jの価格を下回ると思います。

しかも今は「あんしん変更キャンペーン」があるので、SUPER VALUE 21 Jで予約して払い込んでしまい、年始に安い便があれば切り替え、払い戻しを受ければノーリスクで安く乗れるはずです。

天下のANAがこんな苦境に陥るとは誰が予想しただろうか

未だかつて年末の羽田→千歳便がこんな低価格で投げ売りされたことはありません。どれだけぼったくっても、皆が渋々乗るので「ドル箱路線」と称されたほどです。

10年来、散々、羽田→千歳便でボラれてきた身としては、今年は流石のANAもぼったくりはできなかったか……と思いました。けどまあCOVID-19に関しては同情しかなくて、乗れる機会があったら飛行機乗って応援したいですね。九州辺りに旅行に行きたいな〜。

「あんしん変更キャンペーン」はただでさえ客足が遠のく中、安く乗られ、割安で解約され、ANAとしては散々でしょう。

逆にこっちはあまり同情してません。飛行機の割引制度は縛りが多くて理不尽です。今の方が素直だし普通です。是非、このまま続けて欲しいですね。

メモ: 技術系？の話はFacebookから転記しておくことにした。いろいろ修正。