正月に2780円で買った1GB USBメモリ。あと300円出せばトランセントを買えるのに、勝負するバカ。案の定壊れるというか、挿した後に突如デバイス認識が解除されたりと、不安定。

殻を取ってみると赤で囲んだ部分を抑えながら挿せば安定して使える様子。というわけで、拡大鏡を覗きながらこのICのピン一本一本に半田こてを押し当て接触の回復を試みる。今の所直ったっぽい♪

[2007/3/27 追記]

また認識しなくなった。再び殻を開けて抜き差し繰り返すも、不安定。どこだろう・・・

今日はいろんなことが起こるな・・・

ThinkPad S30のバックライトが完全に点かなくなりました＿|￣|○

なんでもバックライトに電圧かけるインバーター回路がすさまじい確率で壊れる とか。写真中央緑色のが、その回路と思われます。さすがに壊れた回路は直せないぞ；；

これ の続き。

• 週末にサーバを停止して60時間連続Memtest86。全く問題なし。
• /var/log/messageに"Unknown cmd fd(7)"とエラーを吐き続けるプロセスを停止。効果なし。

似たような状況の人のページ を見つけた。私の場合は/var/log/messageでHighMem: emptyと出ているので全く同じではないけど、topでキャッシュが4GB以上あるのにOOM-Killer発動なので、似たようなものかなと。ここを参考にして・・・

echo 100 > /proc/sys/vm/lower_zone_protection

これもダメ ＿|￣|○結局彼 と同じくOOM-Killerを止めました。

echo 0 > /proc/sys/vm/oom-kill

さて明日休み中にエラーを出すかどうか。オーバーコミット止めてるし、システム停止はない・・・と祈るｗ しかし・・・なんかやってない? > RedHat[参考]

• Bugzilla
  
• /proc配下のディレクトリ(RedHat EL4マニュアル)

[追記]
これ書いた後に/var/log/messageを見たら、OOM-Killerが発動抑制されてた。システムは元気に稼動中。

Mar 20 22:06:47 foo kernel: oom-killer: gfp_mask=0xd1
Mar 20 22:06:47 foo kernel: Mem-info:
Mar 20 22:06:47 foo kernel: Node 0 DMA per-cpu:
Mar 20 22:06:47 foo kernel: cpu 0 hot: low 2, high 6, batch 1
Mar 20 22:06:47 foo kernel: cpu 0 cold: low 0, high 2, batch 1
Mar 20 22:06:47 foo kernel: cpu 1 hot: low 2, high 6, batch 1
Mar 20 22:06:47 foo kernel: cpu 1 cold: low 0, high 2, batch 1
Mar 20 22:06:47 foo kernel: cpu 2 hot: low 2, high 6, batch 1
Mar 20 22:06:47 foo kernel: cpu 2 cold: low 0, high 2, batch 1
Mar 20 22:06:47 foo kernel: cpu 3 hot: low 2, high 6, batch 1
Mar 20 22:06:47 foo kernel: cpu 3 cold: low 0, high 2, batch 1
Mar 20 22:06:47 foo kernel: Node 0 Normal per-cpu:
Mar 20 22:06:47 foo kernel: cpu 0 hot: low 32, high 96, batch 16
Mar 20 22:06:47 foo kernel: cpu 0 cold: low 0, high 32, batch 16
Mar 20 22:06:47 foo kernel: cpu 1 hot: low 32, high 96, batch 16
Mar 20 22:06:47 foo kernel: cpu 1 cold: low 0, high 32, batch 16
Mar 20 22:06:47 foo kernel: cpu 2 hot: low 32, high 96, batch 16
Mar 20 22:06:47 foo kernel: cpu 2 cold: low 0, high 32, batch 16
Mar 20 22:06:47 foo kernel: cpu 3 hot: low 32, high 96, batch 16
Mar 20 22:06:47 foo kernel: cpu 3 cold: low 0, high 32, batch 16
Mar 20 22:06:47 foo kernel: Node 0 HighMem per-cpu: empty
Mar 20 22:06:47 foo kernel: 
Mar 20 22:06:47 foo kernel: Free pages:      101916kB (0kB HighMem)
Mar 20 22:06:47 foo kernel: Active:263525 inactive:952321 dirty:31553 writeback:9990 unstable:0 free:25479 slab:16510 mapped:182468 pagetables:2447
Mar 20 22:06:47 foo kernel: Node 0 DMA free:4kB min:4kB low:8kB high:12kB active:0kB inactive:0kB present:16384kB pages_scanned:45 all_unreclaimable? yes
Mar 20 22:06:47 foo kernel: protections[]: 0 119400 119400
Mar 20 22:06:47 foo kernel: Node 0 Normal free:101912kB min:2388kB low:4776kB high:7164kB active:1054100kB inactive:3809284kB present:5750780kB pages_scanned:0 all_unreclaimable? no
Mar 20 22:06:47 foo kernel: protections[]: 0 0 0
Mar 20 22:06:47 foo kernel: Node 0 HighMem free:0kB min:128kB low:256kB high:384kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
Mar 20 22:06:47 foo kernel: protections[]: 0 0 0
Mar 20 22:06:47 foo kernel: Node 0 DMA: 1*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4kB
Mar 20 22:06:47 foo kernel: Node 0 Normal: 8362*4kB 4412*8kB 1819*16kB 15*32kB 0*64kB 0*128kB 4*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 101912kB
Mar 20 22:06:47 foo kernel: Node 0 HighMem: empty
Mar 20 22:06:47 foo kernel: Swap cache: add 99675, delete 99675, find 41316/49699, race 0+3
Mar 20 22:06:47 foo kernel: Free swap:       8385724kB
Mar 20 22:06:47 foo kernel: 1441791 pages of RAM
Mar 20 22:06:47 foo kernel: 171909 reserved pages
Mar 20 22:06:47 foo kernel: 476220 pages shared
Mar 20 22:06:47 foo kernel: 0 pages swap cached
Mar 20 22:06:48 foo kernel: Would have oom-killed but /proc/sys/vm/oom-kill is disabled

この話 。＿|￣|○ｶﾝﾍﾞﾝｼﾃｸﾚ

以前から落ちるのはvacuumdb --fullでPostgreSQLの全テーブルをvacuumしたときというのは分かってる。ただ兆候が見つからずいきなりOOM Killerの餌食になってるので、困る。うまく行くときもあるので謎。ほぼ同じソフトウェア構成で、搭載DRAMが2GB & シングルCPUのサーバは何の問題もないので、さらに謎。

とりあえず、--fullオプション付けて一気にやらずに、1テーブルごとにコマンド発行に変更。さて、初日はうまく行きましたが・・・ → もう一回やったら落ちた ＿|￣|○

つぎはカーネルを2.6.9-42.0.2.ELsmp(平穏だった去年８月レベル)に戻してみることに。頼む、安定してくれ・・・→ 落ちた ＿|￣|○

続き

先日のこの話 、Out Of Memory Killer 、通称OOM Killerのせいらしい。キャッシュとしてshared memoryを贅沢に(^^;)使用するPostgresSQLのWrite processが集中的に狙われてます>_<。

直接的にこの仕組みを切るには

echo 0 > /proc/sys/vm/oom-kill

か

echo -17 > /proc/(PID)/oom_adj

ただし前者はRedHat独自&OOM Killer完全停止、後者はカーネル2.6.11以降&プロセスごとに設定。CentOS 4.4のカーネルは現時点2.6.9なので前者。もうひとつの方法として、OOM Killerが発動する１つの原因を作っているメモリのオーバーコミットをさせない方法。具体的には、

echo 2 > /proc/sys/vm/overcommit_memory
echo 90 > /proc/sys/vm/overcommit_ratio

これを起動時に自動設定させるには、/etc/sysctl.confに以下の行を追加。

vm.overcommit_memory = 2
vm.overcommit_ratio = 90

ちなみにオーバーコミットとは何かといいますと、「ありもしないメモリを割り当てる」こと。全てのプログラムは情報を記録するためのメモリが必要で、必要な量をOSに事前申請(malloc)して割り当ててもらう必要があります。最近のJavaとか.NET使っている方はそんなのやったことないかもしれませんが、それはJava runtimeや.NET Frameworkが自動でやってくれているからです。後で追加申請できますが、プログラムが複雑になりやすいので最初に多めに申請する場合が多いです。

従来のOSは申請に応じてマシンのメモリを分け与え、無くなったら以後の申請は却下するわけですが、前述のように使わないのに多めに申請するプログラムが多いと(いや、実際に多いｗ)、有効利用されないメモリが多くなって効率が悪い。

そこで「どうせお前ら、使いもしないのに多めに申請してるんだろ!?」と考えるLinuxは(ｗ)、事前申請は気前良くと受け付けます。たとえマシンにそれだけメモリがなくても。仮想メモリを自動的に増やすという話じゃありません。実メモリ+仮想メモリの合計以上に申請されても許可しちゃうんです。で、各プログラムが実際にメモリを使おうとしたときに初めて使う分だけ本物のメモリを分け与えるわけです。(これだけでも、私には良くそんな面倒なもの作ったなと感心)

問題はもし多くのプログラムが申請した分のメモリを本当に使い出したら・・・。足りません。どうせ実際には使いやしないと高をくくって申請は受けましたが、無いものは無いのです。しかしプログラムはそのメモリにアクセスできないとそれ以上処理できないわけで。他のプログラムが終わってメモリが返却されるのを悠長に待ってはいられない場合もあるでしょう。さて、どうするか? 「しょうがねぇ、いくつかのプログラムお取り潰しにして、そこが使っていたメモリを巻き上げるか・・・」そこでOOM Killerです。

メモリが少ないから何も言わず終了してくれ(会社の経営が苦しいから、何も言わずに辞めてくれｗ)、ってOSからご丁寧に頼んで素直に聞いてくれるプログラムばかりなら良いですが、事は一刻を争う。OOM Killerによるお取り潰しはプログラムに了解無く一方的に行われます。ただ無作為にプログラムを止めるわけではなく、大切なプログラムは見逃すとか独自のルールを持ってます。それに照らし合わせるとメモリを大量消費しているPostgreSQLのwriterが目を付けられると。

上の対策は分け与えるメモリが無いなら申請時に却下するという、従来のメモリ管理にすることになります。メモリの利用効率が悪くなってしまいますが、OOM Killerの出番がなくなります。

参考

• KLab DSAS開発者の部屋
• PostgreSQLのドキュメント

なんかこれ・・・メモリの先物取引とか手形に思えるのは、私だけでしょうか? OSがこんな実装するなんて、ちょっと意外。