と言うかtunedは完全にユーザー空間の実装なのだろうか。カーネル側に自動調整する機能があるわけではない気がするから、調整アルゴリズムとかも全部コードを読めば書いてあるのだろう
2013-10-05 06:32:14@kosaki55tea たまにサーバがフリーズしてしまうのです。kernel.panic = 60 だけども再起動もしてくれない。sshもできなくなるので原因特定できていないのですが、dmesgに残っているメッセージがpage allocation failureしかないのです
2013-10-05 06:44:37@frsyuki 別件だろうね。tcp が ack 返さなくて困る(可能性がある)のは相手サーバであって自分ではない。xen の upcall にバグがあったら知らんが
2013-10-05 06:45:40@frsyuki 仮想マシンなんだから、シリアル繋げれるよね。なんか断末魔の悲鳴でてる?
2013-10-05 06:50:14@kosaki55tea AWSなのでWebコンソールから取れるのですが、断末魔はでてないです。長いこと黙りこくった次のメッセージは、再起動後の起動メッセージ。
2013-10-05 06:51:11@frsyuki さきにこのメッセージの見方を説明しよう。まずコールスタックに do_softirq とあるので、プロセス名は無視して良い
2013-10-05 06:51:48@frsyuki slubのdefault order, min order は最初にdefault order でメモリ確保、失敗したら min order でメモリ確保、それも失敗したらこのメッセージ表示、というフロー。
2013-10-05 06:52:56@frsyuki min order 0 なので、フラグメンテーションとかはなくて純粋に量の問題。
2013-10-05 06:53:26@frsyuki gfp=0x20 なのでGFP_ATOMIC。なので、min/2 まで使えるが、node 0 のfreeがそれを下回ってるので失敗してる
2013-10-05 06:54:00@frsyuki TCPのACKを返すためのTCP ヘッダをアロケーションしようとして失敗してるね
2013-10-05 06:54:40@kosaki55tea ほう、GFP_ATOMICは後で調べておきますが、それはつまりカーネルが使うメモリが全体に不足していると言うことですか? ネットワーク以外のところでも。不足していたらswapが発生するわけではない?
2013-10-05 06:55:39@frsyuki soft irqコンテキストではファイルキャッシュを捨てる処理ができないのです。だから今回のようにファイルキャッシュたんまりケースでは普通のメモリ確保は絶対失敗しないが、GFP_ATOMICは失敗しうる
2013-10-05 06:56:37