目次: Windows
Windowsで「コミット済み」(=仮想メモリの合計)の値を求める方法がさっぱりわかりません。タスクマネージャーの「パフォーマンス」タブには下記のように値が表示されています。
しかしタスクマネージャーの「詳細」タブに表示される、各プロセスのコミットサイズ(=仮想メモリサイズのことらしい)を足しても全く足りません。どういうこと??
コミットサイズが全然信用できない例を挙げれば、AMDのRadeonドライバ関連でAMDRSServ.exeというプロセスがいます。このプロセスをタスクマネージャーで見ると「5MBしか使ってないよ」とおっしゃっています。
ところがプロセスを強制終了させると、突然700MBほど(6.2GB → 5.5GB)仮想メモリが解放されます。700MBも使っているプロセスはありませんでしたが、700MBどこから来た?意味不明ですね。
たぶんカーネル側というかドライバ内で仮想メモリをでかく取ると「コミット済み」と「各プロセスのコミットサイズの合計」の乖離が激しくなるんじゃないか?と予想していますが、調べ方がわかりません。
Windowsを使っていて仮想メモリが枯渇するような事態に陥り、調べる必要が出てきたとしても、タスクマネージャーの表示してる「コミットサイズ」は全然信用できないってことです。ひどい作りだなあ、もう。
新年早々、WindowsとLinuxのメモリ割り当て戦略の基本的な違いをすっかり忘れていて、ひどい目に合いました。
症状としてはSteamでゲームをしてると頻繁にゲームが落ちたり、ブラウザがクラッシュします。
疑った順に、
仮想メモリの枯渇でした。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は仮想メモリ割当てが保守的です。仮想メモリの割り当て上限=物理メモリ+ページファイルの合計となります。
Linuxは仮想メモリの割り当て上限>物理メモリ+スワップファイルの合計となります(over commitment)。
WindowsとLinuxのメモリ割り当て戦略は、利点と欠点が逆になるだけで、どっちもどっちです。
今回の教訓をおさらいすると、Windowsを使っているのに、Linuxと同じノリでページファイルを1GBとか小さいサイズに削ると、速攻で仮想メモリが枯渇してひどい目に合うんでやめようね!ってことです。
記事以外の表示(リンクとか編集ボタンとか)が縦に並んでいて、横長のディスプレイで見たときに邪魔なので、ちょっとだけデザインを変えて縦方向の長さを詰めました。
デザインはあまり詳しくないですが、もっと文字が読みやすくなるようにするにはどうしたら良いんでしょうね……?
年末の帰省チケットを解約したとき(2020年12月17日の日記参照)に価格が激変していたことが気になったので、年末年始の羽田→千歳便の各チケットの価格をプロットしてみました。
どうやらチケットの種類に関係なく、最後に付いているアルファベットで価格帯が決まるようです。Aが一番高くて、B, C, D, ... と安くなっていくようです。10月に予約したSUPER VALUE 75 Hが、今日予約できるVALUE 3 Jより高くなるのはこれが理由でした。
ANAの予約システムは、遠い予約日(1/Mくらい)だと、空席予測を強気に出すのかやや割高の運賃設定をしています。
くらいかな?早朝便、深夜便などは1ランク安くなりがちです。しかし、搭乗日が近づいて(増発を決めてしまった12/30など)、誰も乗らないことに気づき始めると、未だかつて見たことない安さのチケットが出現します。
こんな感じですね。安いなあ。
遠い予約日が強気の価格になるのは、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で予約して払い込んでしまい、年始に安い便があれば切り替え、払い戻しを受ければノーリスクで安く乗れるはずです。
未だかつて年末の羽田→千歳便がこんな低価格で投げ売りされたことはありません。どれだけぼったくっても、皆が渋々乗るので「ドル箱路線」と称されたほどです。
10年来、散々、羽田→千歳便でボラれてきた身としては、今年は流石のANAもぼったくりはできなかったか……と思いました。けどまあCOVID-19に関しては同情しかなくて、乗れる機会があったら飛行機乗って応援したいですね。九州辺りに旅行に行きたいな〜。
「あんしん変更キャンペーン」はただでさえ客足が遠のく中、安く乗られ、割安で解約され、ANAとしては散々でしょう。
逆にこっちはあまり同情してません。飛行機の割引制度は縛りが多くて理不尽です。今の方が素直だし普通です。是非、このまま続けて欲しいですね。
メモ: 技術系?の話はFacebookから転記しておくことにした。いろいろ修正。
目次: 車
車に乗ってるとたまに疑問に思うんですが、燃費ってアクセル開度で決まるんですかね?
同じ勾配、同じアクセル開度なら、毎速2500rpmで変速しても、2速5000rpmまで引っ張って、すぐ3, 4, 5速と変速しても、燃料消費量は同じ??なんてことをFacebookに書いてみたところ、会社の同僚のみなさんから色々教えていただけました。
同じアクセル開度なら、エンジンの燃焼効率の最適点が一番燃費が良いので、1速でぶん回すより、4速くらいの方が一般的には燃費が良いはず、とのことです。レスが超早かったです。さすが車の専門家達の会社だなと痛感しますね。
通常、燃焼効率の最適点は公開されていません。代わりとしてエンジン出力の最大点を使おうと思います。燃焼効率最適点=燃費の最大点、エンジン出力の最大点=加速の最大点であり、この2つは一致しません。ただし、効率が悪いにも関わらず最大出力に達するのは、ちょっと考えにくいですし、一致はしなくてもさほど遠くないだろう、という目論見です。
スバルのEJ20エンジンはいろんな車種に乗っていて、自分のレガシィB4のエンジン性能曲線が探せませんでした……。インプレッサWRX STIのEJ20エンジン性能曲線はすぐに出てきた(パワーユニット : ドライビング - WRX STI - SUBARU)ので、これを参考にしようと思います。
もちろん
辺りはわかってます。
が、まあ、ざっくり言って、トルクカーブは2500〜4500rpmくらいまでピークかつ真っ平らです。ほぼどこで変速しても大丈夫!素晴らしいエンジンですね〜。
2000rpm前後の加速が眠くて、突然速くなる感じがするのも、レガシィが重たいからだと思いこんでいたんですけど、2000〜2500rpmでトルクが急激に立ち上がるエンジン特性からくるものなんですね。見覚えあるなと思って調べたら、昔も同じことを言っていました(2010年9月5日の日記、2010年9月7日の日記参照)。完全に忘れてました。
何年乗ってるんだ、今更かよって感想ですけど……。
Facebookで教えていただいたところによると、EJ20はOBD2端子(On-board diagnosticsという故障診断の信号を送受信できる端子)から燃料消費量の情報が取れるはずなので、それを見たらどうか?ELM327互換のアダプタでBluetoothでスマホにデータを送る手もある、という素晴らしいアイデアをいただきました。
昔に付けたメーター(2011年5月4日の日記参照)で、瞬間燃費が表示できないか試してみようかな。
メモ: 技術系?の話はFacebookから転記しておくことにした。大幅に追記。
実家と話し合って、今年末の北海道への帰省を取りやめました。年末がクッソ暇になりました。
帰省用の飛行機チケットを解約したんですが、ANAが最近やってる「あんしん変更キャンペーン」(ANA公式サイト)により、運賃や解約ルールが意味不明になってます。
買ったチケットは、
計95,040円です。
解約の仕方をいくつか試したところ、払戻金額の見積もりがべらぼうに変わり驚きました。
各パターンで何が起きているのでしょう?個人的な予想に過ぎませんが、
バリュー系チケットの値段は需要連動(ANAの解説)らしく、11月のコロナ再流行で需要が急激に落ち込み、スーパーバリュー75Hとバリュー3Jの逆転現象が発生したのでしょう。この需要連動という想定そのものが「直前に需要が急減する」という事態を想定していない節がありますね。
もし10月くらいにスーパーバリュー系を予約した人は、1万円単位で大損してるはずです。年末に飛行機に乗る人は要確認です。
今のANAの一番良くないところは、普通に解約すると5万円近く大損するところですが、ANAのQAを見る限り「コロナ関連で解約の特別対応はしない、所定のキャンセル料を払え」とあるのでANAとしてはパターン1の解約でANAに5万円寄付せよ、という意思なんでしょうか?
私は、パターン3を試してみたので、手数料含めて2,500円くらいで解約できちゃったように見えます。
予約システムのバグだったんですかね?ちゃんと払い戻しされるかなあ??不安だわあ……。
メモ: 技術系?の話はFacebookから転記しておくことにした。
< | 2021 | > | ||||
<< | < | 01 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | 1 | 2 |
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 | - | - | - | - | - | - |
合計:
本日: