Linux メモリ周りのトラブル調査記事

ここでは、「Linux メモリ周りのトラブル調査記事」 に関する記事を紹介しています。
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
第1回 減り続けるメモリ残量! 果たしてその原因は!?

目的 名称 特徴
システム監視
free
簡易にメモリ使用状況を把握できます。本連載でも述べていますが、出力内容に若干問題があります。
vmstat
メモリ使用状況以外にも CPU 使用率の把握などさまざまな用途に利用可能です。単体ではタイムスタンプ出力機能がなく、指定できる更新間隔も高負荷時にはあてにならないことが欠点と言えます。
sar
最も取得情報量が多いコマンドです。ただ、Active/Inactive(本記事内で後述)が取得できないなど、出力内容は若干柔軟性に欠け、メモリ監視という観点ではvmstatに一歩譲るようです。
プロセス監視
top
管 理者がリアルタイムにシステム状況を見るのに適したツールです。ソート機能や更新頻度変更などいろいろな機能があるので、top画面表示中に「h」か 「?」を押して確認するとよいです。システム監視用にログを取得するには、バッチモード(-bオプション)が利用可能です。
ps
topと同様、リアルタイムでシステム状況を監視するのに適したツールです。Linux版には互換性保持のため多くのコマンドオプションが存在し、育った文化によってどのオプションを使うかが分かれます。ちなみに私は「aux」オプション派。
freeコマンドの出力について:

図中で「-/+ buffers/cache」という行の「used」と「free」に当たる部分は、それぞれ「used-」「free+」と呼ぶことにします。

 それでは、各項目の意味について簡単に説明します。

行名 項目名 意味
Mem
total
総物理メモリ量
used
総物理メモリ使用量からfreeを引いたもの
free
何の用途にも使っていない物理メモリ量
shared
常に0。現在は利用されていない
buffers
ファイルなどのメタデータをキャッシュしている物理メモリ量
cached
ファイルのデータ本体をキャッシュしている物理メモリ量
-/+ buffers/cache
used-
buffers、cachedを含めないused量
free+
buffers、cachedを含めたfree量
Swap
total
Swap領域の総量
used
totalからfreeを引いた量
free
使用していないSwap領域の量

 

ActiveとInactiveはvmstat -aやcat /proc/meminfoなどと入力することで取得できます(図5)。

メモリの利用状況について説明した事柄をまとめると、以下のようになります。

1. MemFreeが少なくなること自体に問題はない
2. freeコマンドは、物理メモリ使用状況を正確に把握するのには向かない
3. freeコマンドを使う場合は、ページキャッシュを考慮したused-とfree+を使う
4. 物理メモリ使用状況の把握にはActiveとInactiveを使う






第2回 減り続ける利用可能メモリ……そしてついにリブート!

ここまで見てきた内容を一覧にしてみました(表4)。

  ユーザー空間 カーネル空間
仮想メモリ
カーネルへの影響:なし
他プログラムへの影響:なし
発生事象:メモリを消費したプログラムで
ENOMEMエラーが発生する
カーネルへの影響:限定的
他プログラムへの影響:なし
OSハングアップという観点では
考慮不要
物理メモリ
カーネルへの影響:なし
他プログラムへの影響:あり
発生事象:
 ・スワップアウト発生
 ・ページキャッシュ減少
 ・OOM-Killer発生
カーネルへの影響:あり
他プログラムへの影響:あり
発生事象:
・スワップアウト発生
・ページキャッシュ減少
・OOM-Killer発生
表4 メモリ不足の分類と発生する事象



最終回 SystemTapで真犯人を捕まえろ!

各回のまとめ

 3回に分けてお届けした番外編ですが、メモリのトラブルシューティングに際して覚えておいてほしいトピックを各回ごとにまとめてみます。

【第1回で覚えておいてほしいこと】

* MemFreeが少なくなることを恐れてはいけない
* freeコマンドの結果は物理メモリ使用量の正確な把握には向かない
* 物理メモリ使用状況把握にはActive、Inactiveを使うべきである

【第2回で覚えておいてほしいこと】

* 仮想メモリと物理メモリの違い
* カーネルにはswapやOOM-Killerなど、物理メモリ枯渇に対する防御機構が存在する
* 利用可能な物理メモリが極限までなくなるとリブートに至る可能性がある

【第3回で覚えておいてほしいこと】

* /proc/meminfoの見方
* カーネルの物理メモリ使用量には把握できない部分があること
* SystemTapによる解析の有効性







20110102追記:
Sun, 26 Oct 2008 C言語:メモリ破壊検出ツール electric fenceの使い方
electric fenceの解説記事。感謝。

このツールは、プログラム中の動的配列(malloc等で確保した配列)の開始位置・終了位置を覚えて これらの配列の領域をポインタ等が踏み越えたときにセグフォで停止させてくれる ものです。ですので、このセグフォによるコア(core)をgdb等のデバッガで確認すれば、 どこで、どの配列の領域侵害で停止したのかが一瞬で分かるようになります。

とのこと。使い方の概要は次のとおりらしい:

インストールは簡単で、ライブラリをインストールするだけです。
いつものごとく、Debianのインストール方法を以下に記述します。

 $ sudo apt-get install electric-fence
これで、electric fenceが使用可能となります。
使い方はいくつもありますが、ここではお手軽な方法を紹介します。 まず、デバッグ対象となるバイナリがdo_hogeだとします。このdo_hogeのメモリオーバーランを 検出するには、

 $ ulimit -c unlimited
 $ LD_PRELOAD=/usr/lib/libefence.so do_hoge args
とします。これで、メモリオーバーランを検出するとその場でセグメンテーションフォルトで 停止してくれ、かつ、そのときのcoreを吐いてくれます。
一行目のulimitコマンドが、linuxシステムにコアを吐かせるようにするコマンドです。
あとは、実行バイナリの頭に「 LD_PRELOAD=/usr/lib/libefence.so 」を付ける だけです。

これで、カレントディレクトリにcoreというファイルが生成されているので、あとは、gdbで どこで止まったか確認しましょう。

 $ emacs
 ・emacs上で「M-x gdb "do_hoge" core」と入力する。
これだけで、プログラムのどの行で停止したのかをgdbが教えてくれます。





Mon, 27 Oct 2008 C言語:セグメンテーションフォルト(セグフォ)時にcore(コア)を吐かせる方法
3通りの方法を解説してくださっている。感謝。


スポンサーサイト
コメント
この記事へのコメント
冒頭のリンクを忘れていたことに気づいたので
http://www.atmarkit.co.jp/flinux/rensai/tantei01/bangai01a.html
に張りました。

スミマセン。
2012/02/07(火) 02:50 | URL | テキトーな備忘録の中の人 #-[ 編集]
コメントを投稿する
URL:
Comment:
Pass:
秘密: 管理者にだけ表示を許可する
 
トラックバック
この記事のトラックバックURL
http://tekitobibouroku.blog42.fc2.com/tb.php/151-f13d9791
この記事にトラックバックする(FC2ブログユーザー)
この記事へのトラックバック
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。