 |
|
|
| 前のページ 1 2 3 4
|
|
| Alicia API機能
|
ここまでの機能の紹介で、pass_through（既存ダンプ解析ツールの実行結果をそのままreturnする）と、load（ダンプ解析スクリプトをローディングする）というAPIが出てきたが、ここではダンプのデータをアクセスするための代表的なAlicia APIを紹介する。
| 書式 |
： get_addr('シンボル名') |
| 機能 |
： 外部参照可能なカーネルシンボル名のアドレスを得る |
| 実行例 |
： |
|
alicia> $utsname = get_addr('system_utsname')
alicia> print $utsname
0xc03539e0
|
|
| 書式 |
： kernel('アドレス', '構造体名', 'メンバ変数名', '型') |
| 機能 |
： 指定されたカーネル構造体のメンバ変数を得る |
| 実行例 |
： |
|
alicia> print kernel($utsname, 'new_utsname', 'sysname', 'char *')
Linux
|
|
| 書式 |
： get_mem(アドレス, ワード数) |
| 機能 |
： 指定されたアドレスのメモリ内容を得る |
| 実行例 |
： |
|
alicia> @chrs = get_mem($utsname, 2)
alicia> print map("$_ ", @chrs)
0x756e694c 0x00000078
|
|
| 解析スクリプト応用編
|
Alicia APIを利用すれば、カーネルダンプを解析するプログラミングが簡単になる。例えば、Linuxカーネルのソースコードでよく使われるlist_for_eachというマクロをAliciaに導入してみる。list_for_eachはlist_head構造体のリンクリストを作成するマクロである。
|
sub list_for_each {
my ($lists, $head) = @_;
for (my $pos = get_mem($head); $pos ne $head; $pos = get_mem($pos)) {
push(@{$lists}, $pos);
}
}
1;
|
このlist_for_eachを利用してファイルロックの情報を表示するスクリプトをAliciaのアーカイブファイルにサンプルとして添付している。解析スクリプトのライブラリパス（ldasDir）に指定されているディレクトリにlocks.ldasという名前でインストールされているので、ぜひダウンロードして参照されたい。
実行結果は、以下のようになる。
|
alicia> lock_status
1: FLOCK 2735 flock1.pl lockedfile
1: ->FLOCK 2736 flock2.pl lockedfile
1: ->FLOCK 2737 flock3.pl lockedfile
2: POSIX 17341 java localDB.lck
3: FLOCK 875 autorun .autorun.lck
4: POSIX 713 kdm kdm.pid
5: POSIX 696 atd atd.pid
6: FLOCK 609 UNKNOWN crond.pid
|
左から、ファイルロックの内部的なID、方法（機構）、プログラム名、ロックしたファイル名である。これは、/proc/locksの内容の一部とファイルロックを行っているタスク情報の一部である。
上記のコマンドを実行したときの/proc/locksの内容は以下のようになる。これと比べると、上記の出力結果が、解析に必要な情報が人にわかりやすい形で編集されていることを実感できるだろう。
|
alicia> !cat /proc/locks
1: FLOCK ADVISORY WRITE 2735 08:05:409632 0 EOF d9060fa0 c044d4c8 f6891e84 00000000 d9060e2c
1: -> FLOCK ADVISORY WRITE 2736 08:05:409632 0 EOF d9060e20 d9060ee4 c044d4d0 d9060fa0 d9060eec
1: -> FLOCK ADVISORY WRITE 2737 08:05:409632 0 EOF d9060ee0 c044d4d0 d9060e24 d9060fa0 d9060fac
2: POSIX ADVISORY WRITE 17341 08:03:442753 0 15 f6891e80 d9060fa4 c86d1fa4 000 00000 f6891e8c
3: FLOCK ADVISORY WRITE 875 08:03:311806 0 EOF c86d1fa0 f6891e84 c86d1f44 00000000 c86d1fac
4: POSIX ADVISORY WRITE 713 08:03:1900735 0 EOF c86d1f40 c86d1fa4 f68a1e84 00000000 c86d1f4c
5: POSIX ADVISORY WRITE 696 08:03:1900734 0 EOF f68a1e80 c86d1f44 f6891f44 00000000 f68a1e8c
6: FLOCK ADVISORY WRITE 609 08:03:1900732 0 EOF f6891f40 f68a1e84 c044d4c8 00000000 f6891f4c
|
|
| なぜPerlなのか？
|
今回は、Aliciaにどのような機能があるかを中心に紹介してきたが、Aliciaで使用している言語がなぜPerlなのかを疑問視している読者がいるかもしれない。その点について簡単に触れておこう。
筆者はPerlを使っていくうちに、ダンプ解析という泥臭い作業には、さまざまな手法や解釈ができてしまうPerlがぴったりであるという結論に至った。Perlは歴史が古いため、ユーザも文書も数多く存在し、実際、軽量言語での開発経験がないメンバーでも、Aliciaの開発作業に入りやすかったという事実を特筆しておきたい。
Perlでの開発の経験から、仮にPerlを楽器に喩えるとすれば、ギターに近いと感じている。簡単なことから複雑なことまで、また、泥臭いことから洗練されたことまでをこなせる幅広さがあり、そこがとても気に入っている。
|
| まとめ
|
今まで、Linuxのソースツリーにはダンプ採取機能は取り込まれておらず、ベンダーやコミュニティにより開発された機能を各ディストリビュータが各々で適用してきた。しかし、最近のLinuxカーネルメーリングリストではダンプ採取についての話題がホットになっている。また、LinuxWorld 2005でも障害発生時のダンプ採取の必要性を訴えるブースが目立ち始めた。Linuxのエンタープライズ分野への適用拡大により、今後は障害発生時にダンプが採取されるケースが確実に増えていくことになるだろう。
メインフレームが提供してきたような迅速な障害解析をLinux上で実現するためには、ダンプ解析ノウハウを蓄積していくための手段が必要である。そこでは、解析手順を文書として残すのではなく、解析スクリプトとして残すことが重要なポイントになる。
当然のことながら、ダンプ解析のためにはカーネルのソースコードレベルでの理解が必要であり、ダンプ解析技術とともにカーネルの知識を持った技術者を育てることも同時に行わなければならない。
そのような技術者の育成に対しても、Aliciaは大変に有効である。なぜなら、実際のデータとカーネルのソースとを同時に検証することができ、その勉強の成果をスクリプトとして残すことができるからである。
まだまだ説明不足かもしれないが、筆者自身もAliciaを武器にダンプ解析技術の向上に努めていきたいと考えている。また、Aliciaを使った解析事例についても積極的に公開していく予定である。読者の方々も、ぜひAliciaのコミュニティに参加し、一緒にAliciaを育てていくことにご賛同頂ければ幸いである。
|
| おわりに
|
最後に、Aliciaの開発にあたって多大なるアドバイスと協力を頂いたNTTデータ社とミラクル・リナックス社のメンバー、およびOSS推進フォーラム・開発基盤ワーキンググループのメンバーに、この場をお借りして感謝の意を表したい。
次回は「カーネル性能評価ツール（LKST）を用いた障害解析」について紹介する。
|
前のページ 1 2 3 4
|
|
|
|
|
著者プロフィール
ユニアデックス株式会社 前原 志好
日本ユニシス（株）入社後、米国UNISYS製メインフレームのカーネルを担当する。2004年4月から、所属組織ごとユニアデックス（株）に転籍。その後OSS関連作業に着手。今年は、メインフレーマーとの掛け橋（トランスレータ）役を担当する。
|
|
|
|
|
|
