ギフハブ

• https://github.com/reliforp/reli-prof

三行要約

• adsr/phpspy の PHP 版みたいな奴として reliforp/reli-prof を趣味で作ってる（2020 年くらいから少しずつ）
• もはや PHP に不可能なことはあまりなく、システムコールやメモリ操作を伴う比較的低レベルのプログラミングさえ可能で、PHPer が PHP を極めるための道ももはや果てしない
• ランタイム好きな人にはデバッガとかサンプリングプロファイラとか作るの超オススメ

なにこれ……

• 別プロセスで動作中の PHP プロセスのコールトレースをのぞき見る PHP プログラム

つまり？

$ ./reli i:trace -- php -r "fgets(STDIN);"

みたくやると、-- から先のコマンドが実行され、

0 fgets <internal>:-1
1 <main> <internal>:-1

0 fgets <internal>:-1
1 <main> <internal>:-1

0 fgets <internal>:-1
1 <main> <internal>:-1
...

みたいな「今こんな関数実行してます」が延々出力される。

$ sudo php ./reli i:trace -p 2182685

みたくやると、プロセス ID 2182685 で実行中の PHP プロセスの動作内容を盗み取り、

0 time_nanosleep <internal>:-1
1 PhpProfiler\Lib\Loop\LoopMiddleware\NanoSleepMiddleware::invoke /home/sji/work/php-profiler/src/Lib/Loop/LoopMiddleware/NanoSleepMiddleware.php:33
2 PhpProfiler\Lib\Loop\LoopMiddleware\KeyboardCancelMiddleware::invoke /home/sji/work/php-profiler/src/Lib/Loop/LoopMiddleware/KeyboardCancelMiddleware.php:39
3 PhpProfiler\Lib\Loop\LoopMiddleware\RetryOnExceptionMiddleware::invoke /home/sji/work/php-profiler/src/Lib/Loop/LoopMiddleware/RetryOnExceptionMiddleware.php:37
4 PhpProfiler\Lib\Loop\Loop::invoke /home/sji/work/php-profiler/src/Lib/Loop/Loop.php:26
5 PhpProfiler\Command\Inspector\GetTraceCommand::execute /home/sji/work/php-profiler/src/Command/Inspector/GetTraceCommand.php:133
6 Symfony\Component\Console\Command\Command::run /home/sji/work/php-profiler/vendor/symfony/console/Command/Command.php:291
7 Symfony\Component\Console\Application::doRunCommand /home/sji/work/php-profiler/vendor/symfony/console/Application.php:979
8 Symfony\Component\Console\Application::doRun /home/sji/work/php-profiler/vendor/symfony/console/Application.php:299
9 Symfony\Component\Console\Application::run /home/sji/work/php-profiler/vendor/symfony/console/Application.php:171
10 <main> /home/sji/work/php-profiler/php-profiler:45

0 time_nanosleep <internal>:-1
1 PhpProfiler\Lib\Loop\LoopMiddleware\NanoSleepMiddleware::invoke /home/sji/work/php-profiler/src/Lib/Loop/LoopMiddleware/NanoSleepMiddleware.php:33
2 PhpProfiler\Lib\Loop\LoopMiddleware\KeyboardCancelMiddleware::invoke /home/sji/work/php-profiler/src/Lib/Loop/LoopMiddleware/KeyboardCancelMiddleware.php:39
3 PhpProfiler\Lib\Loop\LoopMiddleware\RetryOnExceptionMiddleware::invoke /home/sji/work/php-profiler/src/Lib/Loop/LoopMiddleware/RetryOnExceptionMiddleware.php:37
4 PhpProfiler\Lib\Loop\Loop::invoke /home/sji/work/php-profiler/src/Lib/Loop/Loop.php:26
5 PhpProfiler\Command\Inspector\GetTraceCommand::execute /home/sji/work/php-profiler/src/Command/Inspector/GetTraceCommand.php:133
6 Symfony\Component\Console\Command\Command::run /home/sji/work/php-profiler/vendor/symfony/console/Command/Command.php:291
7 Symfony\Component\Console\Application::doRunCommand /home/sji/work/php-profiler/vendor/symfony/console/Application.php:979
8 Symfony\Component\Console\Application::doRun /home/sji/work/php-profiler/vendor/symfony/console/Application.php:299
9 Symfony\Component\Console\Application::run /home/sji/work/php-profiler/vendor/symfony/console/Application.php:171
10 <main> /home/sji/work/php-profiler/php-profiler:45
...

のような感じでコールトレースを垂れ流し続ける。

$ sudo php ./reli i:daemon -P "^/usr/sbin/httpd"

みたく正規表現でプロセスのコマンドラインを指定してやるとデーモンとして動作し、同じマシンで実行中の httpd のワーカープロセスが見つかるたびに自動でアタッチし、内部の mod_php の処理系状態を盗み取ってやはりコールトレースを垂れ流し続ける。

ナニ…コレ……？

• rbspy を参考に作られた phpspy を参考に PHP による実装をした
• ZTS 対応や VM の実行中オペコードの出力など phpspy にない機能も一部付けている
• と言って通じる人は、この先を読まなくていい

何に使える？

• プロファイリング=プログラムの遅いところを見つけられる
  • それも対象プログラム無修正で！
• 動作中のプログラムに性能障害が起きた場合、どこで時間を食ってるかを 止めずに観察できる
• tideways / xhprof や xdebug などのプロファイラでは計測しづらい、速い関数が大量に呼び出されるケースでも計測オーバヘッドが累積せず、比較的正確にボトルネックのイメージを得られる

前提知識

メモリ

• コンピュータにはメモリというデータを覚えておく装置がついてる

プログラム

• プログラムは実行時、メモリにロードされて動作

PHP のプログラム

• PHP のスクリプトは、PHP 処理系という、C 言語で書かれたプログラムが解釈して実行

PHP 処理系の働き方（を超雑に）

• メモリ内にスクリプト（PHP コード）を読み込む

• メモリ内にスクリプトと対応する中間コードを生成（コンパイル）

• 中間コードを解釈

• 中間コードに記述された通り処理を行い、ある種の仮想マシンとして処理系の内部状態（メモリ内容）を更新していく

OS のプロセス

• Linux のような OS は、複数のプログラムを同時並行で動かすための仕組みを持つ
  • マシンを有効に活用するため
• OS 上で動作中のプログラムのことをプロセスと呼ぶ

• 先に説明した通り、プログラムは実行時、メモリにロードされて動作

• OS は各プロセスがそれぞれ固有のメモリ空間（仮想アドレス空間）を持つかのように環境を隔離
  • 複数のプログラム実行（プロセス）が相互に意図せぬ干渉をしないようにするため
  • 別プロセスのメモリ内容にはふつうにはアクセスできない
• CPU の機能を利用

• あるプロセスにおける仮想メモリアドレス 0x10000000 番地は、別のプロセスの仮想メモリアドレス 0x10000000 番地とは異なる内容を持ち得る。

PHP 処理系やその内部状態といった登場人物は全て、とにかくメモリ上のどこかに配置される。

• 外部プロセスのメモリ内容を覗き見る方法
• 外部プロセスのメモリ内のどこに何があるかを知る方法

この 2 つさえ分かれば、なんかすごいことができる

なんかすごいこと ＝ のぞき見

たとえば、動作中の処理系の内部状態をメモリから観察することで、外部プロセスの PHP プログラムが今まさに何をしているか、を、そのプログラムの動作へ影響を与えずに盗み見ることが可能

• よくあるプログラムは関数呼び出しの繰り返しで作られてる
• ある関数が別の関数を呼び出し、終わったら次の関数を呼び出す

• 「今何を実行中か」を大体等間隔でサンプリングして取得する
• サンプリングでよくとれる関数は処理時間が長かったり頻繁に呼び出されてる（ボトルネック）

• ボトルネックを見つければ高速化ができる
  • 速度が問題になったときどこを改善すればどのくらい変わるかが図れる
• 実際に外部プロセスのメモリ内容を読むのはやや大道芸じみたプログラムになる
• でもこんな大道芸が人類の役に立つなんて！うれしい！

構成

今回作ったプログラムは大きく分けて以下のようなモジュールで構成

• /proc/<pid> 下の内容を解釈する部品
• ELF を解釈する部品
• FFI で process_vm_readv(2) や ptrace(2) を呼び、外部プロセスのメモリやレジスタ内容を読み取る部品
• Zend Engine 内部のメモリレイアウトの知識を持ちトレースデータを生成する部品
• コマンドラインインターフェース用の部品
• デーモン動作用の部品
  • 解析対象となる実行中の PHP プロセスを探す部品
  • 解析対象の PHP プロセスを解析する部品
  • 両者をマルチスレッド or マルチプロセスで並列実行させつつ通信で協調させ結果出力をする部品
    • ext-parallel 有効時はマルチスレッド動作するようにしてみている（非有効時はマルチプロセス）
• 出力内容を整形して出力する部品
  • フレームグラフや speedscope 形式での出力も可能に

/proc/<pid>/maps

/proc/<pid>/maps を見ると対象プロセスのメモリマップが取得でき、reli はこれのパーサを持っている。

% sudo cat /proc/10364/maps
56187c10d000-56187c20e000 r--p 00000000 08:07 1181323                    /usr/local/sbin/php-fpm
56187c30d000-56187c6a9000 r-xp 00200000 08:07 1181323                    /usr/local/sbin/php-fpm
56187c70d000-56187cef3000 r--p 00600000 08:07 1181323                    /usr/local/sbin/php-fpm
56187d26a000-56187d30d000 r--p 00f5d000 08:07 1181323                    /usr/local/sbin/php-fpm
56187d30d000-56187d314000 rw-p 01000000 08:07 1181323                    /usr/local/sbin/php-fpm
56187d314000-56187d335000 rw-p 00000000 00:00 0 
56187f100000-56187f2c6000 rw-p 00000000 00:00 0                          [heap]
7f6b76c00000-7f6b76e00000 rw-p 00000000 00:00 0 
7f6b76eb3000-7f6b76f34000 rw-p 00000000 00:00 0 
7f6b76f48000-7f6b76f4b000 r--p 00000000 08:07 1052066                    /lib/x86_64-linux-gnu/libnss_files-2.28.so

見ての通り、各メモリ領域と対応する実行ファイルや .so のパスが含まれている。

mod_php なら .so ファイル、cli や php-fpm なら実行ファイルに PHP の処理系が入っている。

例えば /usr/bin/php というパスにあるファイルで、中身が sl コマンド ということはあまりない筈。

それっぽいパスでさえあれば、PHP 処理系の入ったファイルだとみなしてよさそう。

正規表現でそれっぽいパスを持つ行を抜き出し、そこにあるのが PHP 処理系のファイルの各部分がロードされているメモリアドレスの始点と終点であり、またそのパスが PHP 処理系のパスでもある、ということに。

ELF を解釈する

reli は ELF のパーサを PHP で実装 している。

Linux において、プログラムコードは ELF というファイル形式でディスク上に格納されている。

ELF には大きく分けて、再配置可能オブジェクト（いわゆる .o）、実行可能ファイル（/bin とか /usr/bin に置いてあるような実行したら動くファイル）、共有オブジェクト（いわゆる .so）の 3 種類がある。

といっても便宜上の分類であり、ld.so のように実行可能でもある共有オブジェクト、といったものも存在する。

細かな分類の話は一旦置いておいて、重要なのは、これらのファイルはプログラムのシンボル情報を含んでいる、ということ。

シンボル情報は分割コンパイルされたコードを結合するため、コードの各部品について、どの名前の部品が各ファイルのどの部分に格納されているか、を保持する情報だ。

とにかく ELF ファイルのヘッダや、ヘッダからたどれる様々な情報を解析することで、ある ELF ファイルが別の ELF ファイルとリンクするために提供しているシンボル情報、つまりそのシンボルがメモリ上に配置された際にどのようなアドレスを見ればアクセスできるか、という情報を、抜き出すことができる。

PHP 処理系は EG にその内部状態を格納している。そしてこの内部状態は、xdebug.so や pdo.so といった拡張機能の ELF ファイルと実行時にリンクするため、公開されているシンボル情報を通じて辿ることができる！

一旦ここまでの内容をまとめる。

• cli や fpm といった SAPI では PHP の実行可能ファイル、mod_php なら mod_php の .so ファイルを、/proc/<pid>/maps から探し出す
• これで処理系の ELF ファイルとメモリ上の配置先が手に入る
• ELF ファイルを解析し、シンボル情報を読み取り、メモリ上の配置先にあわせて値を調整すれば、外部プロセスにおける EG の仮想アドレスを特定することができる。
• あとは外部プロセスの指定仮想アドレスのデータに、何らかの方法でアクセスすることができればよい。
• ここで FFI

FFI で process_vm_readv(2) や ptrace(2) を呼ぶ

FFI (Foreign Function Interface)

• FFI は PHP 7.4 で追加された仕組み
• C 言語の関数やデータに PHP からアクセスできる

process_vm_readv(2)

• 呼び出したプロセスのアドレス空間の指定領域へ PID で指定されたプロセスのアドレス空間の指定領域をコピー
• process_vm_readv(2) によってプロセスの壁を超えることができる

FFI 経由で Zend Engine 内部の構造体にアクセスする

• PHP 処理系は C で書かれている
  • 処理系の内部構造は過去にちょっと解説したことがある
    • なおこの記事の後の方で解説した phpspy の解説とかなり似たことを reli でもやってる
• PHP 処理系の内部構造体の定義を php-src から一部抜き出す
• FFI 経由で定義を抜き出したヘッダを読む
• process_vm_readv(2)　で実行中の処理系内部データをコピーしてきたバッファのポインタを PHP 構造体へのポインタとしてキャスト
  • なおバッファが owned=true （デフォルトの設定）で FFI:new により確保されている場合、この元のバッファのポインタを持つ CData が GC される際、ポイント先のバッファ自体も容赦なく GC され、キャスト後のポインタから領域へアクセスしようとすると SEGV になる。よってキャスト前のポインタにはもう用がなくとも、キャスト後のポインタを持つ CData とキャスト前のバッファのポインタを持つ CData をセットで持ち運ぶ必要がある
• \FFI\CData のプロクシを作って PHP の型として各構造体へアクセスできるようにする
  • ちなみに構造体のネストなどでこの CData のメンバに CData がある場合、メンバ側の CData の参照を保持していても外側の CData の参照カウントは増えず、外側の CData の参照カウントが 0 になると普通に全体が GC される。その状態でメンバ側の CData を見に行くと SEGV になる
• PHP 側でポインタ用の型を定義し、process_vm_readv(2) を内部で呼び出すデリファレンサ経由でしかアクセスできないようにする
  • 構造体内のポインタはリモートプロセスの中での仮想アドレスを指しているため直接アクセスすると SEGV になる
• EG 経由でコールトレースをたどる

可視化

• トレース内容はテキストとして出力
  • phpspy の形式に準じてる
• ワンライナーで集計したりできる
• フレームグラフとしての可視化も可能
• speedscope 形式への変換にも対応

その他の枝葉末節

• PHP の stream 関数で procfs を読もうとすると正しいデータを得られないケースがあるため、FFI 経由でファイルを読む処理を別途用意している
• ファイルやメモリ上のバイナリを扱うにあたっては chr() や ord() や \ArrayAccess を利用している

なんで PHP でこんなことを

• FFI 入ったり JIT 入ったりで最近の PHP は Web 以外での利用もできそう感を出してきていたので、試してみた
• PHP コードを最適化するのは PHPer なので、PHPer が自由にいじれるプロファイラがあると便利そう
• もともと低レベル寄りのプログラミングが好きで、仕事で使ってるのは PHP。つまり趣味プログラミングで PHP を使いつつ低レベル寄りのプログラミングができる pet project があれば、仕事の勉強にもなるし欲求も満たせてお得だなと思った
• 最近の PHP は言語的にあまり不足を感じることがなく、Psalm や PHPStan のような静的型解析器を入れるとジェネリクスも付いてくるし型の扱いもガチガチめにでき、普段使いの言語として悪くないという感触が日頃からあった
  • こんな大道芸を含めてさえ、そこまで向いてないタスクというのはもう無いなと思う

得られた学び

• PHP でもうわりとなんでもできる
• 今の PHP では高レベルの設計手法から低レベルの技術詳細までほとんどあらゆる種類の知識とワザが活用可能
  • コンピュータについて学べば学ぶほど PHP でできることは広がり、学びの対象を既存のよくある Web の作り方やその周辺に限る理由はもうない
• ランタイムの大道芸まじ楽しい

将来の展望

• 変数の内容監視など phpspy にある機能を一通り入れる
• 細かい使い勝手の向上
• DWARF 情報を解析して処理系内の C 言語レベルのトレースをあわせて得られるようにしたり、メモリプロファイラ機能をつけるなど、phpspy にもないような機能を足していく
• Perfetto のビューアなど、他の出力形式への対応
• 高速化
• 各コンポーネントを独立したパッケージにし、ドキュメントや API を整理し、PHPer がカスタマイズ可能なプロファイリングフレームワークにする

名前について

• この記事の公開時点でこのツールの名前は sj-i/php-profiler というシンプルなわかりやすい名前だった
• 改修にあたって Zend ライセンスだけでなく PHP ライセンスのコードを使いたくなったが、PHP ライセンスのコードを使う際には「PHPほげほげ」という名前を使ってはいけないという縛り（第 4 条項）がある
• てきとうに選んだ文字列操作関数 strrev() を元の名前に適用して "reliforp-php" となり、これが "reli for p(php)" みたく見えるので、"reli" という名前に変わった

この文書について

• わりと書きなぐってるので、そのうち全体的な文章を清書したりするかもしれない、しないかもしれない