技術共有

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

参考文献:

①mtrace を使用して JVM オフヒープ メモリ リークを追跡する

②Javaメモリ使用量が多い場合のトラブルシューティング事例

1. 調査のアイデア

メモリリーク箇所の取得（詳細なコマンドは参考資料①を参照）

1. jna を使用して Java コードで mtrace を有効にし、メモリ割り当てを追跡する

2. mtrace コマンドを使用してログ ファイルを分析し、メモリ リーク コール ポイントを取得します。

3. arthas は、メモリ リーク コール ポイントのコール スタックをチェックします (コール ポイント アドレスを直接使用できます。関数名は必要ありません)。

メモリリーク内容の取得（詳細なコマンドは参考資料②を参照）

1. pmapコマンドを初めて実行して、Javaプロセスのメモリ使用量を取得します。
2. 一定の時間が経過すると、メモリが増加します。pmap コマンドを再度実行して、Java プロセスのメモリ使用量を取得します。
3. テキスト比較ツールを使用して、前後の 2 つの pmap コマンドの出力を比較します。
4. 新しく追加されたメモリのデータ内容を表示するためのトランスコード

2. 事例の共有

オフラインでサービスをテストする際、QPSが高いとマシンのnio.directbuffer領域が占有するメモリが急激に増加し、コンテナ内でOOMが発生します。

上記のトラブルシューティングのアイデアを使用して、RPC フレームワークがダイレクトバッファ領域に大量のデータを生成していることが最終的に判明しました。実際、QPSが高い場合、セレクタスレッドの数が少なく、消費容量が不足するため、ダイレクトバッファ領域にリクエストとレスポンスのデータが滞留します。