- PR -

dmesg にて swapper: page allocation failure. order:4, mode:0x20

1
投稿者投稿内容
hobit
会議室デビュー日: 2005/07/05
投稿数: 2
投稿日時: 2005-07-05 15:27
dmesg や /var/log/messages に件名のエラーメッセージが頻出しており、
時々、OSがファイルシステムを正しく読めなくなり、
正常なサービスやログインが出来なくなる現象が起きております。
再起動すれば直るのですが、トラブルの原因を解消したいと考えております。
エラーメッセージの全文は文末に記載します。

googleで調べてみたのですが、有力な情報が得られませんでした。
メッセージの内容から推測すると
スワップメモリの割り当てに失敗したというメッセージのようです。
その後はネットワークに関するエラーのようです。
最後にstart_kernelとなり、カーネルが再起動?しているようです。

サーバはwebサーバとして利用しており、eth0をダウンさせると件名のメッセージは出力されなくなります。

FastEthernetとGibabitEthernet間で速度差によるパケットのバッファというかキャッシュというか、そのデータがメモリを必要としているため、スワップを使用してしまっているのかも、との推測で以下のことを試しましたが、解消されません。
・100MbpsのメディアコンバータとGigabitEthernetを直接接続しているのが原因かと思いスイッチングハブを間に入れたのですが、解消されませんでした。
・linkupの状態を確認すると100Mbpsになっておりました。
・txqueuelenの値を100に変更しても解消されません。


件名の現象に関して、情報をお持ちの方ご協力をお願い致します。
解決策をお持ちの方ご教授お願い致します。



サーバの現状
------------------------------------------------------------------------------
OSはTurboLinux10Server カーネルは2.6.8-1です。
e1000のネットワークカードで、100Mbpsのメディアコンバータに直接接続しています。
スペックはP3 1.4MHz / RAM 1GB / HD 36GB RAID 1 です。
ロードアベレージは低いのですが、
メモリは若干不足気味でスワップ領域を1M程度使用している状態です。
------------------------------------------------------------------------------

ifconfigの出力結果
------------------------------------------------------------------------------
eth0 Link encap:Ethernet HWaddr *****************
inet addr:************** Bcast:************** Mask:**************
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3319460999 errors:260 dropped:260 overruns:0 frame:0
TX packets:1412331066 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2944625838 (2808.2 Mb) TX bytes:2040843570 (1946.3 Mb)
Base address:0xcce0 Memory:feb60000-feb80000
------------------------------------------------------------------------------

エラーメッセージ
------------------------------------------------------------------------------
swapper: page allocation failure. order:4, mode:0x20
[<c0139577>] __alloc_pages+0x1b7/0x350
[<c013972f>] __get_free_pages+0x1f/0x40
[<c013c55f>] kmem_getpages+0x1f/0xc0
[<c013d052>] cache_grow+0x82/0x100
[<c013d21c>] cache_alloc_refill+0x14c/0x1f0
[<c013d5ef>] __kmalloc+0x5f/0x70
[<c02548ed>] alloc_skb+0x3d/0xe0
[<c0284094>] tcp_fragment+0x54/0x2e0
[<c02846bc>] tcp_write_xmit+0x11c/0x2b0
[<c0281b51>] __tcp_data_snd_check+0xb1/0xc0
[<c02820ea>] tcp_rcv_established+0x21a/0x830
[<c0118b66>] recalc_task_prio+0xa6/0x1d0
[<c028a553>] tcp_v4_do_rcv+0xe3/0xf0
[<c028ab87>] tcp_v4_rcv+0x627/0x830
[<c0260050>] do_setlink+0x120/0x1b0
[<c02713a4>] ip_local_deliver+0xe4/0x1f0
[<c02717cb>] ip_rcv+0x31b/0x450
[<c025a176>] netif_receive_skb+0x1f6/0x2a0
[<c025a293>] process_backlog+0x73/0x160
[<c025a3df>] net_rx_action+0x5f/0xf0
[<c011ff53>] __do_softirq+0x83/0xa0
[<c011ff97>] do_softirq+0x27/0x30
[<c01084d5>] do_IRQ+0xc5/0xe0
[<c0106be8>] common_interrupt+0x18/0x20
[<c0104030>] default_idle+0x0/0x30
[<c0104054>] default_idle+0x24/0x30
[<c01040c5>] cpu_idle+0x25/0x40
[<c034c72e>] start_kernel+0x16e/0x1b0
------------------------------------------------------------------------------
ぽんす
ぬし
会議室デビュー日: 2003/05/21
投稿数: 1023
投稿日時: 2005-07-05 18:35
引用:

hobitさんの書き込み (2005-07-05 15:27) より:
メッセージの内容から推測すると
スワップメモリの割り当てに失敗したというメッセージのようです。


そうではなくて、物理メモリの割り当てに失敗しています。

引用:

その後はネットワークに関するエラーのようです。


続きに出ているのはこのときのスタックダンプです。

「swapper: page allocation failure. order:4, mode:0x20」は
__alloc_pages() が出しているメッセージです。
order:4 だから16ページですかね。mode:0x20 は gfp_mask
(メモリ取得のモード)が __GFP_HIGH だということを示していますが
私にはなんだかわからないのでパス

追記。
もうちっとソースを読んでみました。てゆーか、同じところに書いてある
緊急時に備えて、カーネルは空きメモリをある程度確保しておくように
していますが、__GFP_HIGH になっているとその空きメモリの最低水準を
ちょっと下回っていてもメモリを取得できます。
いまの場合、__GFP_HIGH が付いているにもかかわらずメモリの取得に
失敗しているわけで、つまり、同様に __GFP_HIGH が付いているヤツが
「予備」のメモリを使い尽くしてしまった、ということになります。
# __GFP_HIGH 以外にも優先されるものはあるがそれについては割愛

なんにしても、必要なメモリが得られていない、という状況です。

スタックダンプを眺めてみると...
alloc_skb() はパケットの中身を入れる場所を用意する関数です。
__kmalloc() で用意しようとしているのだけれど、(間は省略して)
結局 __alloc_pages() で失敗している、ということですね。

対症療法としては、「メモリを増やす」でしょうか。
そもそもの原因は、カーネルがヘタレだとかドライバが腐ってるとか、
なにかありそうな気もしますが... あてずっぽうな対処が許されるなら、
そのへんをアップデートしてみる、とか。
単にメモリが足りないだけ、ということもあるのかしら。

[ メッセージ編集済み 編集者: ぽんす 編集日時 2005-07-05 21:29 ]
hobit
会議室デビュー日: 2005/07/05
投稿数: 2
投稿日時: 2005-07-07 16:13
ご返答ありがとうございます。
とても参考になりました。

メモリを2Gまで増設しました。
件名のエラーは以前よりは少なくなりました。
しかく、なくなりません。

ハードウェアは全て中古で集めたパーツ(DELL)なので
ハードウェアに問題があるのか、
カーネルもしくはドライバに問題があるのか。。。

新品のDELLで同じOSで同じ仕様で構築したマシンも稼動しているのですが、
件名のエラーは出ていません。

ぽんす
ぬし
会議室デビュー日: 2003/05/21
投稿数: 1023
投稿日時: 2005-07-07 22:44
ありゃりゃ、2GBでもダメですか。う〜ん、難儀ですねえ。

引用:

hobitさんの書き込み (2005-07-07 16:13) より:
ハードウェアは全て中古で集めたパーツ(DELL)なので
ハードウェアに問題があるのか、
カーネルもしくはドライバに問題があるのか。。。

新品のDELLで同じOSで同じ仕様で構築したマシンも稼動しているのですが、
件名のエラーは出ていません。


あんまりハードウェアの問題っぽくないと思ったんですが、
どうですかねえ。 すぐ思いつく手としては、以前から使っていた
メモリを引っこ抜いてみる、というのがありますが、うーん...
その新品のマシンと、やってる仕事は同じなんでしょうか?

以下、思いつきのチェック項目。
・メモリは本当に使い切られているか? → vmstat とか free とか
・netstat -an で何か変わった点は無いか?
  TIME_WAIT が何千も残ってるとか
・top、ps 等でメモリをバカ食いしているプロセスが見つからないか?

あとはチューンしていく案でしょうか。
Webサーバということですので、クライアントを受け付ける数を
減らす、とか。
1

スキルアップ/キャリアアップ(JOB@IT)