pg_shmem_allocations view - Mailing list pgsql-hackers
From | Andres Freund |
---|---|
Subject | pg_shmem_allocations view |
Date | |
Msg-id | 20140504114417.GM12715@awork2.anarazel.de Whole thread Raw |
Responses |
Re: pg_shmem_allocations view
Re: pg_shmem_allocations view Re: pg_shmem_allocations view |
List | 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
Attachment
pgsql-hackers by date: