Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 49ff16c

Browse files
author
Maksim Milyutin
committed
Keep profile and history data in shared memory
To simplify interaction between collector process and client backends requesting profile or history data the current patch adds shared data structures to store statistics: the fixed-size shared hash table to keep profile and fixed-size shared array to implement ring buffer for history data. Shared hash table for profile has fixed size specified by `pg_wait_sampling.max_profile_entries` GUC. The least used entries are diplaced from hash table when its overflow encounters. The eviction algorithm is the same that is used in pg_stat_kcache extension - it's based on usage metric stored within hash table entries. The shared structures for profile and history are solely in-memory and not persisted to external disk. So after server restart all statistics fully reset. This is not bad because for wait monitoring it's enough to keep track differential counters in profile statistics. Current patch also makes all timing period GUCs reloadable via SIGHUP. Other GUCs in some way have impact on allocation of shared resources so they are done changable via server restart. The history keeping looks not usable for regular monitoring of wait events so in current patch it's disabled by default by specifying zero value for `pg_wait_sampling.history_period` GUC.
1 parent fc7173a commit 49ff16c

File tree

5 files changed

+453
-765
lines changed

5 files changed

+453
-765
lines changed

‎README.md

+35-23
Original file line numberDiff line numberDiff line change
@@ -27,19 +27,27 @@ When `pg_wait_sampling` is enabled, it collects two kinds of statistics.
2727
recent samples depending on history size (configurable). Assuming there is
2828
a client who periodically read this history and dump it somewhere, user
2929
can have continuous history.
30-
* Waits profile. It's implemented as in-memory hash table where count
31-
of samples are accumulated per each process and each wait event
32-
(and each query with `pg_stat_statements`). This hash
33-
table can be reset by user request. Assuming there is a client who
34-
periodically dumps profile and resets it, user can have statistics of
35-
intensivity of wait events among time.
36-
37-
In combination with `pg_stat_statements` this extension can also provide
38-
per query statistics.
30+
* Waits profile. It's implemented as bounded in-memory hash table where counts
31+
of samples are accumulated per triple of process pid, wait event and query id
32+
(when its computing is enabled on PG server, on versions below 14 this
33+
requires `pg_stat_statements` extension). The least used entries are evicted
34+
when overflow of hash table is encountered. Hash table also can be reset by
35+
user request. Assuming there is a client who periodically dumps profile and
36+
computes differential counters from adjacent dumps, user can have statistics
37+
of intensivity of wait events among time.
38+
39+
Starting from PG14 this extension might activate computing of query id on server
40+
side to enable per query id statistics. The older PG versions require to install
41+
`pg_stat_statements` extension for this purpose.
3942

4043
`pg_wait_sampling` launches special background worker for gathering the
4144
statistics above.
4245

46+
The profile statistics as well as history items are not persisted to disk so
47+
server restart resets all already accummulated data. This is not crucial for
48+
profile counters because we are primarily interested in differential values, not
49+
absolute values of these counters.
50+
4351
Availability
4452
------------
4553

@@ -125,24 +133,28 @@ in-memory hash table.
125133
The work of wait event statistics collector worker is controlled by following
126134
GUCs.
127135

128-
| Parameter name | Data type | Description | Default value |
129-
| ----------------------------------- | --------- | ------------------------------------------- | ------------: |
130-
| pg_wait_sampling.history_size | int4 | Size of history in-memory ring buffer | 5000 |
131-
| pg_wait_sampling.history_period | int4 | Period for history sampling in milliseconds | 10 |
132-
| pg_wait_sampling.profile_period | int4 | Period for profile sampling in milliseconds | 10 |
133-
| pg_wait_sampling.profile_pid | bool | Whether profile should be per pid | true |
134-
| pg_wait_sampling.profile_queries | bool | Whether profile should be per query | true |
136+
| Parameter name | Data type | Description | Default value | Change policy |
137+
| ------------------------------------ | --------- | ----------------------------------------------------------------------------------- | ------------- | ------------- |
138+
| pg_wait_sampling.max_profile_entries | int4 | Maximum number of entries in profile hash table | 5000 | restart |
139+
| pg_wait_sampling.history_size | int4 | Size of history in-memory ring buffer | 5000 | restart |
140+
| pg_wait_sampling.profile_period | int4 | Period for profile sampling in milliseconds (zero value disables profile gathering) | 10 | reload |
141+
| pg_wait_sampling.history_period | int4 | Period for history sampling in milliseconds (zero value disables history gathering) | 0 | reload |
142+
| pg_wait_sampling.profile_pid | bool | Whether profile should be per pid | true | restart |
143+
| pg_wait_sampling.profile_queries | bool | Whether profile should be per query | true | restart |
135144

136145
If `pg_wait_sampling.profile_pid` is set to false, sampling profile wouldn't be
137-
collected in per-process manner. In this case the value of pid could would
138-
be always zero and corresponding row contain samples among all the processes.
146+
collected in per-process manner. In this case the value of pid will be NULL and
147+
corresponding rows contain samples among all the processes.
139148

140-
While `pg_wait_sampling.profile_queries` is set to false `queryid` field in
141-
views will be zero.
149+
__Caution__:
150+
When sampling per pid is enabled, all profile entries for already completed
151+
processes are left in hash table. Therefore, it's neccessary to take into
152+
account periodic flushing of profile to prevent recycling of 32-bit pid values
153+
in profile hash table and as consequence possible increments to profile entries
154+
belonging to some old processes with the same pid values as for current ones.
142155

143-
These GUCs are allowed to be changed by superuser. Also, they are placed into
144-
shared memory. Thus, they could be changed from any backend and affects worker
145-
runtime.
156+
While `pg_wait_sampling.profile_queries` is set to false `queryid` field in
157+
views will be NULL.
146158

147159
See
148160
[PostgreSQL documentation](http://www.postgresql.org/docs/devel/static/monitoring-stats.html#WAIT-EVENT-TABLE)

0 commit comments

Comments
 (0)