5

PostgreSQL はメモリ プールを頻繁に使用し、Valgrind が有効になっている場合は、それらに関する情報を Valgrind に提供しますVALGRIND_CREATE_MEMPOOL

VALGRIND_DO_LEAK_CHECKなどのクライアント リクエストを使用したインクリメンタル リーク チェックと組み合わせるとVALGRIND_DO_ADDED_LEAK_CHECK、大規模で複雑で長寿命のプログラムでメモリの使用状況を追跡するのに非常に役立ちます。

しかし: PostgreSQL には多くのキャッシュがあり、その有効期間はトランザクションのような典型的な境界にまたがる傾向があります。このようなキャッシュ内のメモリが (さまざまな理由で) リークしているように見えることは通常は問題ありませんが、そのようなメモリがスタックのみを使用してキャッシュ コンテキストに割り当てられているかどうかを特定することは必ずしも容易ではありません。

そのため、リーク レポートでメモリ プールを表示し、抑制でそれらをフィルタリングする方法を探しています。理想的には次のようなもの

# Do not copy, this DOES NOT WORK
{
   my_suppression_name
   Memcheck:Leak
   match-leak-kinds: reachable
   pool:CacheMemoryContext           # <---- something like this
   fun:malloc
   fun:AllocSetAlloc
   fun:palloc
   fun:initStringInfo
   fun:apply_work
   ...
}

またはリークレポートでは、次のように:

... 6 (+6) bytes in 1 (+1) blocks are possibly lost in loss record 180 of 942
...    in mempool "CacheMemoryContext"                   <---- Like this
...    at 0x815FFC: MemoryContextAlloc (mcxt.c:771)
...    by 0x817680: MemoryContextStrdup (mcxt.c:1157)

Valgrind mempool を登録するためのインターフェースは名前を参照していないように見えるので、答えは「いいえ」だと思います。PostgreSQL の mempool のヘッダー ブロックには名前が埋め込まれているため、Valgrind にプール名のバイト範囲を教えればよいだけです。

何か足りないのですか、それとも今は不可能ですか?

実行可能な代替手段は、リークチェックレポートをフィルタリングしたり、注釈情報を追加したりするためのプログラムコールバックです。しかし、Valgrind には、これが可能であることを示唆するものは何もありません。

他の人が望んでいたことのように思えるので、私はそれを行う方法を見ていないだけかもしれません.

コンテキスト: キャッシュのどこかに割り当てが必要だと思いますが、TopMemoryContext代わりに PostgreSQL に割り当てられています。そのため、一部として破棄する必要があるキャッシュよりも長生きしています。

4

0 に答える 0