bg_mon
Background worker for monitoring PostgreSQL (by CyberDem0n)
pg_wait_sampling
Sampling based statistics of wait events (by postgrespro)
| bg_mon | pg_wait_sampling | |
|---|---|---|
| 1 | 3 | |
| 66 | 132 | |
| - | 0.0% | |
| 5.2 | 5.6 | |
| 5 months ago | 6 months ago | |
| C | C | |
| MIT License | GNU General Public License v3.0 or later |
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
bg_mon
Posts with mentions or reviews of bg_mon.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2021-12-01.
pg_wait_sampling
Posts with mentions or reviews of pg_wait_sampling.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2022-07-11.
-
Moving from Oracle to Postgres, what should I know?
pg_wait_sampling together with pg_stat_statements gets you nearer to Oracle's ASH/AWR capabilities. PoWA can integrate that (and other interesting extensions) to generate some nice reports.
-
[RDS] Huge spikes in CPU Usage, but the Freeable Memory remains high. How do I configure my DB to use more memory?
Another Another source of high CPU could be wait events. There are no built-in tools in Postgres to monitor them (unless RDS provides some). The approach I'd take on a "regular" Postgres installation is to sample the content of pg_stat_activity and then later analyze that after spikes have occurred. There are several extensions that already provide this, e.g. pg_profile or pg_wait_sampling or pgsentinel
-
Any Tips for Analyzing (Concurrent) Transaction Performance?
pg_wait_sampling
What are some alternatives?
When comparing bg_mon and pg_wait_sampling you can also consider the following projects:
TDengine - TDengine is an open source, high-performance, cloud native time-series database optimized for Internet of Things (IoT), Connected Cars, Industrial IoT and DevOps.
pg_profile - Postgres historic workload reports
pg_show_plans - Show query plans of all currently running SQL statements
pgsentinel - postgresql extension providing Active session history
pgbadger - A fast PostgreSQL Log Analyzer
zson - ZSON is a PostgreSQL extension for transparent JSONB compression
powa - PostgreSQL Workload Analyzer
hstr - bash and zsh shell history suggest box - easily view, navigate, search and manage your command history.
pgBackRest - Reliable PostgreSQL Backup & Restore
bg_mon vs TDengine
pg_wait_sampling vs pg_profile
bg_mon vs pg_profile
pg_wait_sampling vs pg_show_plans
bg_mon vs pg_show_plans
pg_wait_sampling vs pgsentinel
bg_mon vs pgsentinel
pg_wait_sampling vs pgbadger
bg_mon vs zson
pg_wait_sampling vs powa
pg_wait_sampling vs hstr
pg_wait_sampling vs pgBackRest