グラフィカルプロファイラーの開発PythonFunctionTrace

本日、FunctionTraceの作成者による記事の翻訳を共有します。これは、マルチプロセッサおよびマルチスレッドアプリケーションをプロファイリングでき、他のPythonプロファイラーよりも1桁少ないリソースを使用できる直感的なグラフィカルインターフェイスを備えたPythonプロファイラーです。PythonでWeb開発を学んでいるだけなのか、それを長い間使用しているのかは関係ありません。コードが何をしているのかを理解することは常に良いことです。このプロジェクトがどのように登場したか、その開発の詳細について-さらにカットの下で。

---

前書き

Firefoxのプロファイラは、中のFirefoxの礎石だったプロジェクト量子時代。サンプルエントリを開くと、コールツリー、スタックダイアグラム、ファイアダイアグラムなどを含む強力なWebベースのパフォーマンス分析インターフェイスが表示されます。すべてのデータフィルタリング、スケーリング、スライス、および変換アクションは、共有可能なURLに保存されます。結果はバグレポートで共有したり、調査結果を文書化して他のレコードと比較したり、情報をさらに調査するために渡すことができます。Firefox DevEditionには、プロファイリングスレッドが組み込まれています。このフローにより、通信が容易になります。私たちの目標は、Firefox以外のすべての開発者が、生産的にコラボレーションできるようにすることです。



以前、Firefox Profilerは、LinuxperfおよびChromeプロファイルで始まる他の形式をインポートしていました。時間の経過とともに、開発者はより多くのフォーマットを追加してきました。今日、Firefoxを分析ツールに適合させる最初のプロジェクトが登場しています。FunctionTraceはそのようなプロジェクトの1つです。マットは楽器がどのように作られたかについて話しています。

FunctionTrace

私は最近、開発者がPythonコードで何が起こっているのかをよりよく理解するのに役立つツールを作成しました。FunctionTraceは、Python用のサンプリングなしのプロファイラーであり、5％未満の非常に低いオーバーヘッドで変更されていないアプリケーションで実行されます。FirefoxProfilerと統合されていることに注意することが重要です。これにより、プロファイルをグラフィカルに操作できるため、パターンの検出やコードベースの変更が容易になります。



FunctionTraceの開発目標を確認し、技術的な実装の詳細を共有します。最後に、ちょっとしたデモで遊んでみます。

FirefoxProfilerで開かれたFunctionTraceプロファイルの例。

動機としての技術債務

コードベースは時間の経過とともに大きくなる傾向があります。特に、多くの人が参加する複雑なプロジェクトに取り組む場合。一部の言語は、この問題をうまく処理します。たとえば、JavaIDEの機能は何十年も前から存在しています。または、Rustとその強力なタイピングにより、リファクタリングが非常に簡単になります。他の言語のコードベースが成長するにつれて、維持するのが難しくなるように見えることがあります。これは特に古いPythonコードに当てはまります。少なくとも今はすべてPython3ですよね？



大規模な変更を加えたり、見慣れないコードをリファクタリングしたりすることは非常に難しい場合があります。プログラムのすべての相互作用とその機能を確認すると、コードを正しく変更するのがはるかに簡単になります。多くの場合、私は自分が触れることを意図していなかったコードの断片を書き直していることに気づきます。視覚化でそれを見ると、非効率性は明らかです。



何百ものファイルを読まなくても、コードで何が起こっているのかを理解したかったのです。しかし、私のニーズに合ったツールが見つかりませんでした。また、UIの作業量が多かったため、このようなツールを自分で作成することに興味を失いました。そして、インターフェースが必要でした。 Firefoxプロファイラーに出くわしたとき、プログラムの実行をすばやく理解したいという私の希望が再燃しました。



プロファイラーは、実装が難しいすべての要素を提供しました。これは、スタックプロット、期限付きログマーカー、ファイアチャートを表示し、その性質が有名なWebブラウザーにバインドされている安定性を提供する直感的なオープンソースユーザーインターフェイスです。適切にフォーマットされたJSONプロファイルを記述できるツールはすべて、前述のすべてのグラフィカル分析機能を再利用できます。

FunctionTraceデザイン

幸い、Firefoxプロファイラーを発見した後、私はすでに1週間の休暇を計画していました。そして、私と一緒に楽器を開発したいと思っている友人がいました。彼はまたその週休みを取りました。

目的

FunctionTraceの開発を開始したとき、いくつかの目標がありました。

1. プログラムで発生するすべてを表示する機能。
2. .
3. , .

最初の目標は、設計に大きな影響を与えました。最後の2つは、エンジニアリングの複雑さを追加しました。同様のツールを使用した過去の経験から、関数呼び出しが短すぎないことが不満であることがわかりました。1ミリ秒の追跡記録を記録するが、重要で高速な機能がある場合、プログラム内で起こっていることの多くを見逃していることになります。



また、すべての関数呼び出しを追跡する必要があることもわかっていました。したがって、サンプリングプロファイラーを使用できませんでした。また、私は最近、Python関数が他のPythonコードを実行するコードに、多くの場合シェルミドルウェアスクリプトを介して時間を費やしました。これに基づいて、子プロセスを追跡できるようにしたかったのです。

初期実装

複数のプロセスと子孫をサポートするために、クライアントサーバーモデルを採用しました。 PythonクライアントはトレースデータをRustサーバーに送信します。サーバーは、プロファイルを生成する前にデータを集約および圧縮します。プロファイルは、Firefoxプロファイラーで使用できます。強力なタイピング、一貫したパフォーマンスと予測可能なメモリ使用量の追求、プロトタイピングとリファクタリングの容易さなど、いくつかの理由でRustを選択しました。



クライアントをと呼ばれるPythonモジュールとしてプロトタイプ化しましたpython -m functiontrace code.py。これにより、組み込みのトレースフックを使用して実行をログに記録することが簡単になりました。元の実装は次のようになりました。

def profile_func(frame, event, arg):
    if event == "call" or event == "return" or event == "c_call" or event == "c_return":
        data = (event, time.time())
        server.sendall(json.dumps(data))

sys.setprofile(profile_func)

サーバーはUnixドメインソケットでリッスンしています。次に、データはクライアントから読み取られ、FirefoxプロファイラーによってJSONに変換されます。



プロファイラーは、パフォーマンスログなどのさまざまなタイプのプロファイルをサポートします。しかし、内部プロファイラー形式のJSONを生成することにしました。サポートされている新しいフォーマットを追加するよりも、必要なスペースとメンテナンスが少なくて済みます。プロファイラーはプロファイルバージョン間の下位互換性を維持することに注意することが重要です。つまり、現在のバージョンのフォーマット用に設計されたプロファイルは、将来ダウンロードされるときに自動的に最新バージョンに変換されます。プロファイラーは、整数の識別子を持つ文字列も参照します。これにより、重複排除を使用して大幅なスペース節約が可能になります（使用するのは簡単ですが）indexmap）。

いくつかの最適化

ほとんどの場合、元のコードは機能しました。関数の呼び出しと戻りのたびに、Pythonはフックを呼び出しました。フックは、ソケットを介してサーバーにJSONメッセージを送信し、目的の形式に変換しました。しかし、それは信じられないほど遅かった。ソケット呼び出しをバッチ処理した後でも、一部のテストプログラムの少なくとも8倍のオーバーヘッドが見られました。



このようなコストを確認した後、Python用のCAPIを使用してCレベルに下げました。また、同じプログラムでオーバーヘッド係数は1.1になりました。その後、別の主要な最適化を実行し、を介しtime.time()てrdtsc操作の呼び出しを置き換えることができました。clock_gettime()..。関数を複数の命令に呼び出し、64ビットのデータを生成することによるパフォーマンスのオーバーヘッドを削減しました。ミッションクリティカルなパスでPython呼び出しと複雑な演算を連鎖させるよりもはるかに効率的です。



複数のスレッドと子プロセスのトレースがサポートされていることを説明しました。これはクライアントの最も難しい部分の1つであるため、いくつかの下位レベルの詳細について説明する価値があります。

複数のストリームのサポート

すべてのスレッドのハンドラーは、を介してインストールされthreading.setprofile()ます。スレッドの状態を設定するときに、このようなハンドラーを介して登録します。これにより、Pythonが実行され、GILが保持されていることが確認されます。これにより、いくつかの仮定が単純化されます。

// This is installed as the setprofile() handler for new threads by
// threading.setprofile().  On its first execution, it initializes tracing for
// the thread, including creating the thread state, before replacing itself with
// the normal Fprofile_FunctionTrace handler.
static PyObject* Fprofile_ThreadFunctionTrace(..args..) {
    Fprofile_CreateThreadState();

    // Replace our setprofile() handler with the real one, then manually call
    // it to ensure this call is recorded.
    PyEval_SetProfile(Fprofile_FunctionTrace);
    Fprofile_FunctionTrace(..args..);
    Py_RETURN_NONE;
}

フックが呼び出されるとFprofile_ThreadFunctionTrace()、構造が割り当てられThreadStateます。この構造には、スレッドがイベントをログに記録してサーバーと通信するために必要な情報が含まれています。次に、初期化メッセージをプロファイルサーバーに送信します。ここでは、新しいストリームを開始するようにサーバーに通知し、時間、PIDなどの初期情報を提供します。初期化後、フックをFprofile_FunctionTrace()実際のトレースを行うフックに置き換えます。

子プロセスのサポート

複数のプロセスを操作する場合、子プロセスはPythonインタープリターを介して開始されると想定しています。残念ながら、子プロセスはで呼び出されない-m functiontraceため、それらを追跡する方法がわかりません。子プロセスが確実に監視されるように、起動時に$ PATH環境変数が変更されます。これにより、Pythonが以下を認識している実行可能ファイルを指していることが保証されますfunctiontrace。

# Generate a temp directory to store our wrappers in.  We'll temporarily
# add this directory to our path.
tempdir = tempfile.mkdtemp(prefix="py-functiontrace")
os.environ["PATH"] = tempdir + os.pathsep + os.environ["PATH"]

# Generate wrappers for the various Python versions we support to ensure
# they're included in our PATH.
wrap_pythons = ["python", "python3", "python3.6", "python3.7", "python3.8"]
for python in wrap_pythons:
    with open(os.path.join(tempdir, python), "w") as f:
        f.write(PYTHON_TEMPLATE.format(python=python))
        os.chmod(f.name, 0o755)

-m functiontraceラッパー内 で、引数を持つインタープリターが呼び出されます。最後に、起動時に環境変数が追加されます。この変数は、プロファイルサーバーとの通信に使用されるソケットを示します。クライアントが初期化され、環境変数がすでに設定されていることを確認すると、クライアントは子プロセスを認識します。次に、既存のサーバーインスタンスに接続し、そのトレースを元のクライアントのトレースと相関させます。

FunctionTraceを今すぐ

今日のFunctionTraceの実装には、上記の実装と多くの共通点があります。大まかに言えば、顧客は次のようなFunctionTrace呼び出しを通じて追跡されますpython -m functiontrace code.py。この行は、カスタマイズのためにPythonモジュールをロードしてから、Cモジュールを呼び出してさまざまなトレースフックを設定します。これらのフックには、上記のsys.setprofileメモリ割り当てフックと、builtins.printまたはなどの興味深い機能を備えたカスタムフックが含まれますbuiltins.__import__。さらに、インスタンスfunctiontrace-serverが生成され、インスタンスと通信するようにソケットが設定され、将来のスレッドと子プロセスが同じサーバーと通信することが保証されます。



すべてのトレースイベントで、PythonクライアントはMessagePackエントリを送信します..。最小限のイベント情報とストリームメモリバッファのタイムスタンプが含まれています。バッファがいっぱいになると（128KBごと）、共有ソケットを介してサーバーにフラッシュされ、クライアントは引き続きそのジョブを実行します。サーバーは各クライアントを非同期でリッスンし、トレースをブロックしないように個別のバッファーにすばやく消費します。次に、各クライアントに対応するスレッドは、各トレースイベントを解析し、適切な最終形式に変換できます。接続されているすべてのクライアントが終了すると、各トピックのログが結合されて完全なプロファイルログになります。最後に、すべてがファイルに送信され、Firefoxのプロファイラーで使用できるようになります。

学んだ教訓

Python Cモジュールは、大幅に高い電力とパフォーマンスを提供しますが、同時に高いコストがかかります。より多くのコードが必要であり、優れたドキュメントを見つけるのは難しく、すぐに利用できる機能はほとんどありません。 Cモジュールは、高性能のPythonモジュールを作成するための十分に活用されていないツールのようです。これは、私が見たFunctionTraceプロファイルのいくつかに基づいて言います。バランスをお勧めします。パフォーマンスの低いミッションクリティカルなコードのほとんどをPythonで記述し、Pythonが輝いていないプログラムの部分に対して内部ループまたはCセットアップコードを呼び出します。



読みやすさの必要がない場合、JSONのエンコードとデコードは非常に遅くなる可能性があります。に切り替えましたMessagePackクライアントとサーバーの通信用であり、ベンチマーク時間を半分に短縮しながら、同じように簡単に操作できることがわかりました。



Pythonでマルチスレッドプロファイリングをサポートすることは非常に困難です。以前のPythonプロファイラーの主要な機能ではなかった理由は理解できます。高いパフォーマンスを維持しながらGILを操作する方法を理解するまでには、いくつかの異なるアプローチと多くのセグメンテーションエラーが必要でした。

オンラインのSkillFactoryコースを受講することで、要求された職業をゼロから取得したり、スキルと給与をレベルアップしたりできます。

• Python for Web開発コース（9か月）
• 職業Web開発者（8か月）
• データサイエンスの専門家をゼロからトレーニングする（12か月）
• - Data Science (14 )
• - Data Analytics (5 )
• (18 )

E

• Machine Learning (12 )
• « Machine Learning Data Science» (20 )
• «Machine Learning Pro + Deep Learning» (20 )
• (6 )
• DevOps (12 )
• iOS- (12 )
• Android- (18 )
• Java- (18 )
• JavaScript (12 )
• UX- (9 )
• Web- (7 )