路地裏 ソース解読研究所: カーネルダンプのスタック情報
ダンプ解析をしつつ、自分の理解を確認するために、カーネルダンプのスタックの見方の基本を書いてみます。間違いを発見した方はぜひコメントに入力しておいてください。 このエントリでは、各プロセスのスタックを見るための基本的な情報を記しておきます。 まず最初にpsでプロセス一覧を取得します。 -------------------- crash> ps PID PPID CPU TASK ST %MEM VSZ RSS COMM 0 0 0 c0322a80 RU 0.0 0 0 [swapper] > 0 1 1 f7e110b0 RU 0.0 0 0 [swapper] > 0 1 2 f7e10b30 RU 0
路地裏 ソース解読研究所: カーネルを覗いてみよう
本日、ダンプを読んでいて思いました。 「そうだ、勉強のためならわざわざ障害が起きたダンプファイルを用意して、ダンプを読む必要はないんだ」ってことに。 ですので、日曜日の朝ではありませんが、「ちょっとした冒険」をしてみましょう。 手元に用意するもの - ML40(crashコマンド入り) - 動作しているカーネルと同じバージョンのkernel-debuginfoパッケージ ML40用のkernel-debuginfoは、 http://ftp.miraclelinux.com:/pub/Miracle/ia32/standard/4.0/updates/unsupported/RPMS にあります。 さて、kernel-debuginfoを入手したら、システムにインストールしてください。 * バージョンはお手元のもので構いません。 ----------------------- # rpm
Linuxでクラッシュダンプを採取(3) 〜 クラッシュダンプは何故とるの？ 〜 : DSAS開発者の部屋
この数日間、Linux でクラッシュダンプを採取する方法について検証していますが、そもそも何故クラッシュダンプを取る必要があるのでしょうか。目的を見失ってしまうのは寂しいのでこのへんで少し確認しておきたいと思います。 ・不具合の原因を解析できる これを聞いて「ええええっ・・」って思う人もいるでしょうね。 原理的には可能だとわかってはいても、実際にやるには気力と根性と感性と時間が必要です(笑) そんな私も「Linuxカーネルの解析ができますっ！」なんてとても言えたものではありません。 それなのに何故クラッシュダンプを採取しようとしているか・・・ それは ・問題発生時に動いていたプロセスを知ることができる ・問題発生時にオープンしていたファイルを知ることができる ・問題発生時のロードアベレージなどを知ることができる ・問題発生時のログを採取することができる ・問題を引き起こしたプロセスが特定で
Linuxでクラッシュダンプを採取(2) 〜 カーネルパニックを起こしてみる 〜 : DSAS開発者の部屋
前回は、カーネルパニック時にkexecでセカンドカーネルを起動できる仕組みまで整えてみました。 今回は、実際にセカンドカーネルを読み込ませてみて動作確認をしてみたいと思います。 kexec -p --args-linux --elf32-core-headers --append="文字列" ファイル名 オプションの意味は以下の通り。 -p パニックが起きたらセカンドカーネルを起動する --args-linux Linuxカーネルスタイルのオプションを使用する --elf32-core-headers elf32形式でコアヘッダを用意する --append=STRING カーネルに渡すコマンドラインオプションを指定する ということで、こんなコマンドを組み立ててみました。 kexec -p \ --args-linux \ --elf32-core-headers \ --append="r
Linuxでクラッシュダンプを採取(1) 〜 kexec + kdump を使ってみる 〜 : DSAS開発者の部屋
専用パーティーションを切らずにシステムを構築してしまったがために、クラッシュダンプを採取できなくて苦しんでいる人（って私ですが）にとってはとっても魅力的な仕組みがカーネルに取り込まれたみたいです。導入手順も Documentation/kdump/kdump.txt に非常にわかりやすく書かれているので、比較的スムーズに組み込むことができそうな予感がします。 kexec の機能を利用して別のカーネル（kdumpを組み込んだもの）を起動すると、/proc/vmcore から元のカーネルのクラッシュダンプを採取できるというものなので、通常利用するカーネル（以下、ファーストカーネル）と、パニック時に動き始めるカーネル（以下、セカンドカーネル）の二つのカーネルを作る必要があります。 以下、kdump.txt より抜粋 A) First kernel or regular kernel: -----
路地裏 ソース解読研究所: 最強の割り込み
カーネルストール。これは厄介な敵です。 カーネルPANICならば、最近のカーネルに備わっているdump機能が働いて、カーネルダンプが取れたりするので、さっさとrebootするのを待つばかりです。 一方でカーネルストールの場合、よくあるのはログインしようとしてもなぜかプロンプトが返ってこないとか、キーは入力できないけどマウスカーソルの位置だけ動くとか、微妙感漂う状況に陥ることがあります。 今日はそんな時の強い味方、NMIについて調べてみましょう。 まず、NMIって何でしょう。一般人の味方 Googleで調べてみます。 http://www.nifty.com/webapp/digitalword/word/020/02083.htm こんなページがひっかかりました。何々? 「Non-Maskable Interrupt - マスク不可能な割り込みのこと。ソフトウェアでこのNMIを禁止すること
実行中のアプリケーションを外から観察するコマンド。 - こせきの技術日記
strace システムコールをトレース。カーネルと何を話しているか。 strace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 straceを使ったデバッグ - SourceForge.JP Magazine : オープンソースの話題満載 Linuxカーネルの作り出す世界 − ＠IT自分戦略研究所 - ふつうのLinuxプログラミング 青木峰郎 システムコールとライブラリ関数 − ＠IT自分戦略研究所 システムコール・ライブラリルーチン - UNIX の部屋 ltrace 共有ライブラリの呼び出しをトレース。*.soと何を話しているか。 ltrace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 ltrace で共有ライブラリの関数呼び出しをトレースする - bkブログ 404 - エラー: 404 - Linux JF ƒ‰ƒCƒuƒ‰ƒŠ‚ÌŠ
Open Tech Press | ハウツー：/procディレクトリを活用する
/procディレクトリは不思議な存在だ。本当に存在しているわけではないのだが、ディレクトリ内を見て回ることができる。ディレクトリ内にある各ファイルの容量は0で、バイナリでもテキストでもないのだが、ファイル属性を確認したりファイルの中身を表示したりすることができる。この特殊な/procディレクトリには、カーネル、プロセス、設定用パラメータなどに関して、Linuxシステムについてのあらゆる詳細な情報がある。そのため/procディレクトリを学ぶことで、Linuxのコマンドの仕組みを学んだり、さらにはシステム管理的なことをいくらか行ったりすることなどができる。 Linuxではあらゆるものをファイルとして扱うようになっていて、例えばデバイスさえも（/devディレクトリ内の）ファイルとしてアクセスする。「普通の」ファイルは、テキストファイルかバイナリファイルのどちらか（ことによるとデバイスファイルやパ
あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー
お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinux で top して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と
マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
naoyaのはてなダイアリー - 負荷とは何か
調べごとをしたので blog に書いて理解を深めようのコーナーです。長文です。 Linux でシステム負荷を見る場合にお世話になるのが top や sar (sysstat パッケージに同梱されてるコマンド) などのツールです。 top ではシステム統計のスナップショットを見ることができます。今システムがどういう状態かなーというときは top が便利。 top - 08:16:54 up 3 days, 14:43, 6 users, load average: 0.18, 0.07, 0.03 Tasks: 43 total, 2 running, 41 sleeping, 0 stopped, 0 zombie Cpu(s): 18.2% us, 0.0% sy, 0.0% ni, 81.8% id, 0.0% wa, 0.0% hi, 0.0% si一方の sar では10分ごとのシ
読学のススメ
【特別】エミナルクリニック池袋東口院の気になる口コミまとめ＆行く前に知りたい口コミ5選まとめ：更新 なんて気になったので、エミナルクリニックの池袋東口院についてSNSやネットで調べてみました。そう思ってSNSを中心に調べてみたら、、、口コミや評判も良いじゃない♪ちなみに、似たようなサービスや商品があるかも？なので、今回調べてみたのはこちらになります。お得なチャンス期間！～が狙い目！エミナルクリニックで全身脱毛をスタートさせるのに最適！このページの目次OPEN更新：エミナルクリニックの池袋東口院でお得に申し込みするなら特設サイトでした！エミナルクリニック池袋東口院の住所や最寄り駅、アクセスは？【写真付き】エミナルクリニック池袋東口院のアクセス方法を一から説明してみたエミナルクリニック池袋東口院の地図気になる！エミナルクリニック医療脱毛院のインスタの口コミや評判は？医療脱毛院や脱毛中の様子エミ
目次 - Linux Kernel Documents Wiki - Linux Kernel Documents - OSDN
トップページへ Linuxカーネルに関する技術情報を集めていくプロジェクトです。現在、Linuxカーネル2.6解読室の第2章までを公開中。 目次まえがき第0章 Linuxカーネルの構成要素 0.1 Linuxカーネルとは 0.2 Linuxカーネルのソースコード 0.3 Linuxカーネル機能の概要 0.4 カーネルプリミティブ 0.5 プロセス管理 0.6 メモリ管理 0.7 ファイルシステム 0.8 ネットワーク 0.9 プロセス間通信 0.10 Linuxカーネルの起動 0.11 Linuxカーネルの動作例 Part 1 カーネルプリミティブ第1章 プロセススケジューリング 1.1 マルチタスク 1.2 プロセスとは？ 1.3 プロセス切り替え 1.4 プロセスディスパッチャの実装 1.5 プロセススケジューラ 1.6 プロセススケジューラの実装 1.7 事象の待ち合わせ 1.8 最
KOF 2008 の発表資料 - naoyaのはてなダイアリー
KOF 2008 での発表資料「はてな流大規模データ処理」を以下にアップロードしました。 http://bloghackers.net/~naoya/ppt/081108huge_data.ppt 一部参考文献からの引用 (Introduction to Information Retrieval から Vector space model の図、たつをの ChangeLog から転置インデックスの図) があります。この場を借りて感謝。 環境によってはおそらくフォントの表示がいまいちだと思いますが、ご了承ください。 追記 SlideShare にアップロードしました。 081108huge_data.pptView SlideShare presentation or Upload your own. (tags: linux mysql) 追記: メモリはディスクの 150 倍について
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linuxでクラッシュダンプを採取(4) 〜 セカンドカーネルがやるべきこと 〜 : DSAS開発者の部屋