特定条件下のclone(2)を4倍速くする - 人間とウェブの未来
とあるサーバで妙にシステムCPUの使用率が高い現象が置きておりました。 そこで、まずはざっくりとperf topでプロファイルをとってみると、以下のようになっていました。 22.38% [kernel] [k] copy_pte_range 18.44% [kernel] [k] zap_pte_range 11.13% [kernel] [k] change_pte_range 3.58% [kernel] [k] page_fault 3.32% [kernel] [k] page_remove_rmap また、各プロセスのstraceを眺めていると、cloneで0.05秒とかなり時間がかかっているようです。これだと単純計算で1コアで秒間20回のcloneでコア100%占有してしまう程度の非常に低速な処理しかできないことになります。 sudo strace -T -o/dev/stdo
カーネルスレッドのループと停止をカーネルモジュールで実装 - 人間とウェブの未来
以前Linuxのカーネルスレッドがループして暴走したときに、カーネルスレッドの扱いを調べていた時期があって、それの簡単な動きを再現するべくカーネルモジュールを作りました。まずは、自力で試したい人は以下を見ずに試すと良いでしょう。 まずはカーネルスレッドをループさせる カーネルスレッドは、所謂ps上で[kthread_dayo]みたいな感じで見えるプロセスの事です。厳密にはユーザランドのプロセスも定期的にカーネル側の処理が走るときは[]付けになったりするのですが、簡単には上記のような状態とします。これをユーザランドのプログラミングで作ることは難しいのですが、カーネルモジュールを使えばすごく簡単につくれます。 まずは以下のようにカーネルスレッドをループさせるコードを書きます。 #include <linux/module.h> #include <linux/sched.h> #include
小崎資広さん「人に依存しないデバッグのために、道具の使い方を知ってほしい」〜RubyKaigi 2015基調講演 2日目 | gihyo.jp
RubyKaigi 2015レポート 小崎資広さん「人に依存しないデバッグのために、道具の使い方を知ってほしい」〜RubyKaigi 2015基調講演 2日目 12月11日～13日、ベルサール汐留にて「RubyKaigi 2015」が開催されました。今年も基調講演が毎日一つずつ行われました。その模様をレポートします。 RubyKaigi 2015 2日目の基調講演は、世界で唯一の、LinuxのコミッタでありRubyのコミッタでもある小崎資広さんです。今回、小崎さんは「Linux loves Ruby. Ruby Loves Linux - How to debug your linux box」と題して、発表しました。 Linux portメンテナのお仕事 小崎さんは、Ruby Core Teamでの自分の役割を「Linux Portメンテナ」と称し、これまでの仕事の内容を紹介しました。
デバッグ/コアダンプ - S.T.K Wiki
コアダンプ プログラムのとある時点でのメモリやレジスタの内容をファイルに保存したもの。主にプログラムが異常終了した際の原因特定のために使用される。 コアダンプを生成するには 一昔前は特に設定しなくてもSEGVするとcoreを吐く環境もあった気がするが、イマドキ(?)のLinuxディストリでは 以下のコマンドを実行しないとコアを吐かないようになってるのがほどんどだ。(以下の解説では主にLinux環境を想定している) $ ulimit -c n # nはcoreファイルの最大サイズ(KB単位)coreファイルのサイズに上限を設けないあるいは気にする必要がないのであれば以下でもいい。 $ ulimit -c unlimitedまた、参考文献によるとcoreファイルの生成を抑制するのはシェルの仕事らしい。 言われてみればulimitコマンドはシェルの組み込みコマンドだ。 $ which ulim
QEMU上のLinuxカーネルをGDBでデバッグする
プログラムがセグメンテーションフォルトで不正終了した場合に、GDBで原因 調査するというのはよく聞く話である。しかし、こういったソフトウェア開発 の後行程で使用するだけではなく、前行程でも使うべきである。これは挙動が よく分からないプログラムの動作確認にGDBが有効であるからだ。 今回は特にprint文が動作しない段階のLinuxカーネルの動作をGDBで確認する。 ただし、あくまでQEMU上での動作である為、QEMUでサポートしていないハード やQEMUが再現しきれていないハードの動作部分については未対応である。そう いった場合はICEなどの治具を用いる必要がある。 1. カーネルコンフィグの設定 CONFIG_DEBUG_KERNELを有効にする。 Symbol: DEBUG_KERNEL [=y] Type : boolean Prompt: Kernel debugging Loca
Linuxカーネルハックに興味があるけど特にネタが無いんだよな〜って人向けの小ネタ - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Linuxカーネルに興味があるんだけど特に作りたいものってないんだよなーなんて割とあると思う訳です。俺とか。。。 まあ、kernelnewbiesのメーリングリストでもよく見る話題かと思います。この辺なんかもそうですね。 で、そんな時にオススメできるのがkmemleak。カーネルに組み込まれたメモリーリーク検出ツールです。 使い方は至って簡単でカーネルのコンフィグレーションにあるKernel memory leak detectorを有効にしたカーネルを普通に使えばOK。カーネルはメインラインのrcでもtipでもlinux-nextでも何でも良いと思います。 設定の場所はKernel Hacking -> Memory Debugging -> Kernel memory leak detectorにチェックをするのと、 その下のMaximum kmemleak early log ent
sysのCPU使用率が高い場合にその内訳を調べる方法 - ablog
OSレベルで sys のCPU使用率が高い場合に perf*1 を使って、何の処理の割合が高いか調べる方法です。 perf は 特定のプロセスだけでなくOS全体の統計を見れる カーネル（sys）とユーザー（user）の両方を見れる ところが非常に便利だと思う*2。 準備 ひたすら write システムコールを発行し続けるプログラムを作成する $ cat write_loop.c #include <unistd.h> int main(void) { while(1) { write(1, "foo\n", 4); } } コンパイルする $ gcc write_loop.c -o write_loop 実行権限を付与する $ chmod u+x write_loop 検証 ひたすらwriteシステムコールを発行するプログラムを実行する $ ./write_loop > /dev/null
シェルスクリプトのデバッグは typeset または declare を使うと良いかも - よんちゅBlog
はじめに つい最近知った便利なデバッグ方法 (長年シェルスクリプトを書いているのに知らなかった。これが常識だったら恥ずかしい…) シェルスクリプトのデバッグでは echo で変数の中身を見るという原始的な方法をよく使うかと思います。 いわゆる プリントデバッグ というやつですね。 もう少し詳しいデバッグが必要な場合は、 set -x と set +x でデバッグしたい部分を囲むという方法もあります。 今回は プリントデバッグ で使う echo の代わりに typeset or declare を使うと良いというお話です。 プリントデバッグは typeset or declare を使おう typeset or declare は変数宣言などでよく使うコマンドですが、変数の中身を見るのにも使えます。 echo と比べて何が良いのかというと、変数の中身はもちろん変数名や変数の型も表示してくれ、
[memo] Apache Core Dump on CentOS
CentOS で Apacheモジュール のデバッグをしていて、 Core Dump を吐かせようと思ったときに少し迷ったのでここにメモしておく。 Core Dump はプログラムがクラッシュしたときのメモリの状態を示すものであり、gdb でいろいろ解析ができるのでデバッグ時に重宝するのだが、サイズが結構巨大になる。それに Production な環境では不要なものなので、ディストリビューションはあの手この手で Core Dump を出力しないようにしているのが普通だ。 ググるといろんなやり方が書いてあるけれども、ディストリビューションによって手順が違うのに加えて、一般論も混じっていてかなりわかりづらい。CentOS(Red Hat系ディストリビューション) で一番簡単なのは以下だ。 これは、/etc/init.d/functions で ulimit を環境変数で毎回設定していることによ
アドレスからソースコードの位置を探すコマンド - syuu1228's blog
カーネル飛んだ時とか、RIP（EIP）からobjdump -d vmlinuxを見ながら位置を探したりしてたんだけれども、binutilsに含まれてるaddr2line使えばソースコードの行数簡単に見れたのね。 まぁ、これがあるからといってobjdumpでディスアセンブルさせて眺めたいケースが無くなるわけじゃないから、併用した方がいいんだろうけど。 objdumpで探す $ cd ~/linux $ objdump -l -d vmlinux |less (/ ffffffff81525fc0と入力してReturn） ffffffff81525fc0 <dev_queue_xmit>: dev_queue_xmit(): /home/syuu/bcube-linux-stable/net/core/dev.c:2464 ffffffff81525fc0: 55 push %rbp ffff
gdb のRPM に付属する /usr/bin/gstack, /usr/bin/gcore コマンド - hibomaの日記
Scientific Linux 6 系の gdb の RPM に /usr/bin/gstack, /usr/bin/gcore というスクリプトが含まれているのを知りました。どちらも gdb をラップしたシェルスクリプトです。 (追記: CentOS5 の gdb にも入ってました ) /usr/bin/gstack 指定したプロセス(マルチスレッドの場合は全スレッド)のスタックトレースを表示します monit の例 # /usr/bin/gstack `cat /var/run/monit.pid` Thread 2 (Thread 0x7fd3ea10a700 (LWP 27548)): #0 0x0000003cb48dea63 in poll () from /lib64/libc.so.6 #1 0x000000000041c9c7 in can_read_ms () #2
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.tartanllama.xyz/c%20%20/2017/03/31/writing-a-linux-debugger-registers/
なんかトレースするはなし
AndroidのNFC機能でFeliCaの読み書きをする | −ゆめログ− | ゆめみスタッフブログ