問題タブ [pprof]

Go アプリにメモリ リークがあると思われます。

何が起こっているのかを調べるために、 を試していpprofます。

読み取りを理解するのに苦労しています。に接続する場合go tool pprof http://localhost:6060/debug/pprof/heap?debug=1の出力例は次のとおりです。

(下手な難読をお許しください)

funcAメモリの約 70% を消費していると解釈されますが、これは約 12MB です。

今topでも示しています：

これは、1.371 GB のメモリが使用されていることを示唆しています....どこに消えたのですか?

また、pprofドキュメントは非常に倹約的です。それをどのように使用すべきかを理解することさえ困難です。私たちのバイナリはデーモンです。例えば：

1. で読み取りを開始した場合go tool pprof http://localhost:6060/debug/pprof/heap、これはこの特定の時点での 1 回の読み取りですか、それとも経時的な集計ですか?
2. text後でもう一度ヒットinteractive modeすると、同じ値が報告されるように見えることがあります。私たちは実際に同じ価値観を見ているのでしょうか? go tool pprof...新しい値を取得するために再起動する必要がありますか?
3. スタック内の特定のポイントの完全なヒープ、または特定の go ルーチンの読み取りですか....???

最後に、この解釈は正しいですか ( http://localhost:6060/debug/pprof/から):

バイナリには 64 個の open go ルーチンと合計 45MB のヒープ メモリがありますか?

tcmalloc を使用してアプリケーションをコンパイルし、HEAPPROFILE 環境変数を使用してヒープ ファイルを取得しました。

約 10MB ごとに新しいヒープ ファイルが作成され、tcmalloc ページによると、pprof ツールを使用してヒープ ファイルを比較し、追加の解放されていないオブジェクト (リークの可能性) を確認できます。

結果: ... 合計: 4600.7 MB

0x00000000009f1d25 は適切なアドレスですが、このデータをどうすることもできません。

helloworld アプリケーションで同じことを実行しようとしました

ここでは、すべての関数に明確な名前が付けられており、リークが BigNumber コンストラクターからのものであることがはっきりとわかります。

上記のアドレスの意味を理解するための正しい方向に誰かが私を向けることができますか?

プロファイリング プログラムでは、次のコマンドを使用します。

その結果、Web モードで次の図が得られます。

golangブログの同じ写真のように、この関数内で費やされた時間ではなく、関数呼び出しの数を表示するにはどうすればよいですか?

PS 同様の質問があります。しかし、pprof (kcachegrind やその他のツールなし) だけでそれを行うにはどうすればよいでしょうか?