pg_shmem_allocations view

Andres Freund <andres@2ndquadrant.com>

From: Andres Freund <andres@2ndquadrant.com>
To: pgsql-hackers@postgresql.org
Date: 2014-05-04T11:44:17Z
Lists: pgsql-hackers

Attachments

Hi,

I've more than once wanted to know what allocated shared memory in
postgres installation is used for. Especially with more an more
extensions around that's quite useful.

Thus I've written a patch to add a new SRF/VIEW
pg_get_shmem_allocations/pg_shmem_allocations that shows the contents of
the shared memory index:

postgres=# SELECT * FROM pg_shmem_allocations ORDER BY size DESC;
                 key                 |     off     |    size     | allocated
-------------------------------------+-------------+-------------+-----------
 Buffer Blocks                       |   286242528 | 17179869184 | t
 Buffer Descriptors                  |   152024800 |   134217728 | t
 Checkpointer Data                   | 17584720352 |    41943080 | t
 XLOG Ctl                            |   134234112 |    16804496 | t
 CLOG Ctl                            |   151038624 |      525312 | t
                                     | 17627719648 |      366624 | f
 Backend Activity Buffer             | 17584379168 |      272000 | t
 SUBTRANS Ctl                        |   151563936 |      263168 | t
 OldSerXid SLRU Ctl                  | 17584225696 |      131648 | t
 MultiXactMember Ctl                 |   151892960 |      131648 | t
 Shared Buffer Lookup Table          | 17466111712 |      131184 | t
 shmInvalBuffer                      | 17584653184 |       66104 | t
 Async Ctl                           | 17626666048 |       65856 | t
 MultiXactOffset Ctl                 |   151827104 |       65856 | t
 Fast Path Strong Relation Lock Data | 17583882752 |        4100 | t
 Backend Status Array                | 17584373304 |        3672 | t
 PROCLOCK hash                       | 17583785856 |        2160 | t
 PREDICATELOCKTARGET hash            | 17583886856 |        2160 | t
 PREDICATELOCK hash                  | 17583957632 |        2160 | t
 pg_stat_statements hash             | 17626731952 |        2160 | t
 SERIALIZABLEXID hash                | 17584175184 |        2160 | t
 LOCK hash                           | 17583684096 |        2160 | t
 Background Worker Data              | 17584651184 |        1992 | t
 Wal Receiver Ctl                    | 17626663712 |        1192 | t
 Backend Client Host Name Buffer     | 17584378064 |        1088 | t
 Backend Application Name Buffer     | 17584376976 |        1088 | t
 ProcSignalSlots                     | 17584719472 |         864 | t
 Sync Scan Locations List            | 17626665120 |         656 | t
 Async Queue Control                 | 17626665776 |         244 | t
 Control File                        |   134233856 |         240 | t
 AutoVacuum Data                     | 17626663432 |         224 | t
 BTree Vacuum State                  | 17626664904 |         216 | t
 PMSignalState                       | 17584719288 |         180 | t
 Shared MultiXact State              |   152024608 |         176 | t
 Proc Array                          | 17584373192 |         108 | t
 PredXactList                        | 17584149248 |          88 | t
 Proc Header                         | 17584357360 |          88 | t
 Wal Sender Ctl                      | 17626663656 |          56 | t
 pg_stat_statements                  | 17626731904 |          48 | t
 Buffer Strategy Status              | 17583684064 |          32 | t
 RWConflictPool                      | 17584184832 |          24 | t
 Prepared Transaction Table          | 17584651168 |          16 | t
 FinishedSerializableTransactions    | 17584225664 |          16 | t
 OldSerXidControlData                | 17584357344 |          16 | t
(44 rows)

I think this is quite worthwile information. It'd possibly be better of
in an extension, but the relevant dastructures aren't public.

The attached patch doesn't contain documentation because I wasn't sure
that others would be interested in the feature.

Greetings,

Andres Freund

PS: Yes, the checkpointer's allocation is crazy. The fsync queue is
sized by NBuffers which is absurd.

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Commits

  1. Add pg_shmem_allocations view.