Re: RFC: Detailed reorder buffer stats dumps
От | Ashutosh Bapat |
---|---|
Тема | Re: RFC: Detailed reorder buffer stats dumps |
Дата | |
Msg-id | CAExHW5sk7cPbdYic1YQj3Q7KbZs7nx2p5MDJ6S0jZvnueo+9NA@mail.gmail.com обсуждение исходный текст |
Ответ на | RFC: Detailed reorder buffer stats dumps (Craig Ringer <craig@2ndquadrant.com>) |
Список | pgsql-hackers |
On Wed, May 5, 2021 at 4:03 PM Craig Ringer <craig@2ndquadrant.com> wrote: > > Hi all > > I'm thinking of piggy-backing on the approach used in the "Get memory contexts of an arbitrary backend process" patch inorder to provide access to detailed reorder buffer content statistics from walsenders on request. > > Right now the reorder buffer is mostly a black-box. I mostly rely on gdb or on dynamic probes (perf, systemtap) to seewhat it's doing. I intend a patch soon to add a couple of fields to struct WalSnd to report some very coarse reorder bufferstats - at least oldest buffered xid, number of buffered txns, total bytes of buffered txns in memory, total bytesof buffered txns spilled to disk. > > But sometimes what I really want is details on the txns that're in the reorder buffer, and that's not feasible to exportvia always-enabled reporting like struct WalSnd. So I'm thinking that the same approach used for the memory contextstats patch might work well for asking the walsender for a detailed dump of reorder buffer contents. Something likea per-buffered-txn table of txn topxid, start-lsn, most recent change lsn, number of changes, number of subxids, numberof invalidations, number of catalog changes, buffer size in memory, buffer size spilled to disk. > +1. Will be really useful to troubleshoot what's going on in the ReorderBuffer. If we put that in WalSnd it will not be useful for the connections which are using normal backends to get logical changes through built-in functions. -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: