pg_shmem_allocations view

Поиск
Список
Период
Сортировка
От Andres Freund
Тема pg_shmem_allocations view
Дата
Msg-id 20140504114417.GM12715@awork2.anarazel.de
обсуждение исходный текст
Ответы Re: pg_shmem_allocations view
Re: pg_shmem_allocations view
Re: pg_shmem_allocations view
Список pgsql-hackers
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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: need of anonymous record
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pg_shmem_allocations view