Thread: LWLock statistics collector

LWLock statistics collector

From
ITAGAKI Takahiro
Date:
Hi,

Here is a patch to collect statistics of LWLocks.
The following information are available on pg_stat_lwlocks view:
  - sh_call : number of locked for share mode
  - sh_wait : number of blocked for share mode
  - ex_call : number of locked for exclusive mode
  - ex_wait : number of blocked for exclusive mode

This feature is for developers, so available only if LWLOCK_STAT is defined
(default off). Otherwise, stab functions are installed.

There is room for discussion.
  - Should not collect information for shared buffers?
        If not, we can reduce consumption of memory for stats.
  - Information for LWLockConditionalAcquire()
        It is not gathered now because of the size limitation of LWLockStat
        struct. I intended the total size of LWLock to be less than 64bytes.
  - Information for spinlocks
        Number of sleeps in s_lock() might be useful for analyzing
        spinlock-level lock contentions.
  - Documentation
        Where to document such a feature for only developers?
  ...

Comments welcome.


# SELECT * FROM pg_stat_lwlocks;
 kind |           lwlock           | sh_call | sh_wait | ex_call | ex_wait
------+----------------------------+---------+---------+---------+---------
    0 | BufFreelistLock            |       0 |       0 |    1237 |       0
    1 | ShmemIndexLock             |       0 |       0 |     437 |       0
    2 | OidGenLock                 |       0 |       0 |       0 |       0
    3 | XidGenLock                 |   80086 |       9 |    8174 |       0
    4 | ProcArrayLock              |  162491 |      59 |   16231 |      38
    5 | SInvalLock                 |  163423 |       0 |     180 |       0
    6 | FreeSpaceLock              |       0 |       0 |     399 |       0
    7 | WALInsertLock              |       0 |       0 |   67214 |     247
    8 | WALWriteLock               |       0 |       0 |    8028 |      12
    9 | ControlFileLock            |       0 |       0 |      16 |       0
   10 | CheckpointLock             |       0 |       0 |       0 |       0
   11 | CheckpointStartLock        |    8028 |       0 |       0 |       0
   12 | CLogControlLock            |   22449 |       9 |    8028 |       4
   13 | SubtransControlLock        |   32731 |       0 |       4 |       0
   14 | MultiXactGenLock           |       0 |       0 |       0 |       0
   15 | MultiXactOffsetControlLock |       0 |       0 |       0 |       0
   16 | MultiXactMemberControlLock |       0 |       0 |       0 |       0
   17 | RelCacheInitLock           |       0 |       0 |       0 |       0
   18 | BgWriterCommLock           |       0 |       0 |    1185 |       0
   19 | TwoPhaseStateLock          |       0 |       0 |       0 |       0
   20 | TablespaceCreateLock       |       0 |       0 |       0 |       0
   21 | BtreeVacuumLock            |       0 |       0 |      12 |       0
   22 | BufMappingLock             |  322414 |       1 |     315 |       0
   23 | LockMgrLock                |       0 |       0 |  207585 |    6927
   24 | BufferIO                   |       0 |       0 |    2295 |       0
   25 | BufferContent              |  522714 |     362 |   83375 |     324
   26 | CLogBuffer                 |       0 |       0 |       0 |       0
   27 | SubTransBuffer             |       0 |       0 |       0 |       0
   28 | MultiXactOffsetBuffer      |       0 |       0 |       0 |       0
   29 | MultiXactMemberBuffer      |       0 |       0 |       0 |       0
(30 rows)

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center


Attachment

Re: LWLock statistics collector

From
Tom Lane
Date:
ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> Here is a patch to collect statistics of LWLocks.

This seems fairly invasive, as well as confused about whether it's an
#ifdef'able thing or not.  You can't have system views and pg_proc
entries conditional on a compile-time #ifdef, so in a default build
we would have a lot of nonfunctional cruft exposed to users.

Do we really need this compared to the simplistic dump-to-stderr
counting support that's in there now?  That stuff doesn't leave any
cruft behind when not enabled, and it has at least one significant
advantage over your proposal, which is that it's possible to get
per-process statistics when needed.

If I thought that average users would have a need for LWLock statistics,
I'd be more sympathetic to expending effort on a nice frontend for
viewing the statistics, but this is and always will be just a concern
for hardcore hackers ...

            regards, tom lane