killproc の dtrace が殺されてしまう2017年10月21日 12時02分49秒

OOM killer が呼ばれるのを、dtrace で観察しようと思った。OOM は「Out Of Memory」の略。

プロセスが選ばれてから、最後に解放されるまでの順序を探りたい。

$ dtrace -n 'fbt::killproc:entry{stack()}'
これで、まずはプロセスが落されるのを見付けれられると思ったが、そんなに簡単では無かったようだ。

pagedaemon が OOM Kill をやるのだが、メモリが枯渇している状況なので、dtrace が反応しない。dtrace 自体もスワップアウトされていたり、ページアウトされていたりする。また、シグナルの伝達も遅いので、kill シグナルが送られても、なかなかメモリが解放されずに、pagedamon が他のプロセスも殺し始めて、dtrace も落される。

vm_pageout_scan に、関数の呼び出しと終了以外の dtrace の観察点が仕掛けられているのを見付けた。

SDT_PROVIDER_DEFINE(vm);
SDT_PROBE_DEFINE(vm, , , vm__lowmem_scan);
...
                SDT_PROBE0(vm, , , vm__lowmem_scan);
dtrace でどのように呼び出せば良いかを調べる。
$ dtrace -l | grep lowmem_scan
39458         vm            kernel                              none vm-lowmem_scan
$ dtrace -n 'vm:::vm-lowmem_scan{stack()}'
          CPU     ID                    FUNCTION:NAME
  0  39458              none:vm-lowmem_scan
              kernel`0xc0b8d220

  0  39458              none:vm-lowmem_scan
              kernel`0xc0b8d220
カーネルから直接呼ばれているみたいだ。これは、11-STABLE の結果。11.2-RELEASE が前回のリリースだ。

コメント

コメントをどうぞ

※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。

※なお、送られたコメントはブログの管理者が確認するまで公開されません。

名前:
メールアドレス:
URL:
コメント:

トラックバック

このエントリのトラックバックURL: http://uyota.asablo.jp/blog/2017/10/21/8709756/tb

※なお、送られたトラックバックはブログの管理者が確認するまで公開されません。