トラブルシューティングの極意―達人に訊く問題解決のヒント

第4回 [サーバ・インフラ・ネットワーク編]サポート観点から見た―トラブル時の情報収集法

この記事を読むのに必要な時間:およそ 4 分

トラシュー事例(上級編①)
「過去のパフォーマンス問題について調査したい」

過去のパフォーマンス問題について調査したい場合には,前提条件として,事象発生前から継続してパフォーマンスデータを取得していることが必要となります。RHELではそのような用途に利用できる,sysstatパッケージを用意しています。

sysstatパッケージに含まれるsarは,広い範囲に渡るシステムの稼働情報を取得し記録します。sysstatサービスが起動している場合には,デフォルトで10分おきに取得しています。データは,/var/log/sa配下に保存され,1日が経過するごとにバイナリ(saXX)をテキスト(sarXX)に変換しています。

注意する点としては,バイナリデータはsarのバージョン間で互換性がないこと,また,sarは一定期間経過するとファイルがローテートしますので,sosreportを利用するなどして事象発生後,少なくとも1週間以内に取得することが推奨されます。図5は,sarに記録されているCPU使用率の例となります。

図5 sarの出力結果(CPU使用率)

Linux 2.6.32-504.8.1.el6.x86_64 (localhost.localdomain)    2015-02-09    _x86_64_    (1 CPU)

08:38:45 PM     LINUX RESTART

08:40:01 PM   CPU   %usr   %nice   %sys  %iowait  %steal   %irq  %soft  %guest   %idle
08:50:01 PM   all   0.52    0.00   0.09     2.54    0.01   0.00   0.00    0.00   96.84
08:50:01 PM     0   0.52    0.00   0.09     2.54    0.01   0.00   0.00    0.00   96.84
09:00:01 PM   all   0.02    0.00   0.08     0.50    0.01   0.00   0.00    0.00   99.40
09:00:01 PM     0   0.02    0.00   0.08     0.50    0.01   0.00   0.00    0.00   99.40
09:10:01 PM   all   0.23    0.00   0.31     1.09    0.03   0.00   0.00    0.00   98.33
09:10:01 PM     0   0.23    0.00   0.31     1.09    0.03   0.00   0.00    0.00   98.33
(...省略...)

このようにsarの情報から過去のシステムの稼動状況を確認することができます。今回紹介したCPU使用率以外にも,メモリ,スワップ,ディスク,ネットワーク,ロードアベレージなどの観点から調査できます。詳しくは,man1 sarを参照してください。

トラシュー事例(上級編②)
「システムがハングした」

このような状況のトラブルシューティングで有用となる情報は,その事象が発生している最中に取得されたvmcoreとなります。システムハングの場合,ログやシステムの稼働情報なども正常に取得できていないことが多く,事象が発生している状況で取得されたvmcore以外で調査できないためです。

vmcoreについては,前節で触れたkdumpサービスを利用します。注意する点としては,kdumpサービスを起動しただけでは,カーネルパニックには対処できますが,システムがハングしたという事象には対応できないことです。よってほかの方法でシステムがハングしている最中に意図的にカーネルパニックさせる必要があります。そのために,表1のカーネルパラメータを利用します。

表1 カーネルパニックさせるパラメータ

パラメータ内容
①kernel.softlockup_panicsoft lockupを検出した際にパニックさせる
②kernel.hung_task_panichung taskを検出した際にパニックさせる
③vm.panic_on_oomOut of Memoryを検出した際にパニックさせる
④kernel.sysrqSysrqファシリティの有効化
⑤kernel.unknown_nmi_panicハードウェアからのNMIを検出した際にパニックさせる
⑥kernel.panic_on_unrecovered_nmiハードウェアからのNMIを検出した際にパニックさせる
⑦kernel.panic_on_io_nmiハードウェアからのNMIを検出した際にパニックさせる

それぞれ(1:有効,0:無効)

①~③は,カーネル側で検出できるプロセスの状態から自動的にパニックさせるパラメータです。それぞれ次のような状態を示します。①のsoft lockupはプロセスがCPUを長時間占有している状態を指します。②のhung taskは,プロセスが長時間割り込み不可の待ち状態であることを指します。③のOut of Memoryはメモリ枯渇の状態を指します。

④については,Sysrqファシリティ(特殊なキーコンビネーション,⁠Alt][SYSREQ]+<command>)の有効化です。Sysrqファシリティを有効化している場合には,⁠Alt][SYSREQ][C]にてシステムをクラッシュさせることができます。

⑤~⑦はハードウェアによって,どのNMIを手動で発行できるかということは異なりますので,ハードウェアの実装に従って設定してください。

筆者のお勧めは,④と⑤~⑦の中から利用できるものを設定することです。理由は,任意のタイミングで手動でパニックさせられるためです。紹介したカーネルパラメータの設定は,/etc/sysctl.confで行います。

vmcoreの解析にはcrashユーティリティを利用しますが,誌面の関係上,参考文献の紹介に留めます。


本稿では,情報収集という観点からトラブルシューティングの際に利用できる手法を紹介してきました。ここで紹介したパッケージや設定を必須のものとして,よりよいシステム設計に役立てていただければと思います。

Software Design

本誌最新号をチェック!
Software Design 2017年12月号

2017年11月18日発売
B5判/176ページ
定価(本体1,220円+税)

  • 第1特集
    ITエンジニアと数学
    数学プログラミング入門
  • 第2特集
    AIやディープラーニングで注目される
    気になるGPU超入門
  • 特別付録
    IIJ謹製「インターネット便利帳」

著者プロフィール

野波圭吾(のはけいご)

所属:レッドハット株式会社

仕事内容,略歴:外資系ハードウェアベンダーでインフラ構築にかかわったのち,レッドハット株式会社に移りサポート業務に従事するようになる。一般のお客様向けのフロントライン業務を経て,特定のお客様向けのテクニカルアカウントマネージャ職へ異動し現在に至る。現職では,Red Hat Enterprise Linux ならびに Red Hat OpenStack Platformを中心に担当している。OpenStack との関連から Ceph を現在勉強中。

最近の興味のあること:ロードバイクのために始めたはずの筋トレにはまって,今では筋トレを中心とした生活です。あと,OpenStackを理解するために,Python も触りはじめました。

Twitter:@spilejam

バックナンバー

トラブルシューティングの極意―達人に訊く問題解決のヒント

バックナンバー一覧

コメント

コメントの記入