Octopussy
pgbadger
| Octopussy | pgbadger | |
|---|---|---|
| - | 6 | |
| 151 | 3,382 | |
| 2.0% | - | |
| 0.0 | 7.9 | |
| over 3 years ago | about 2 months ago | |
| Perl | Perl | |
| GNU General Public License v3.0 only | PostgreSQL License |
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.
Octopussy
We haven't tracked posts mentioning Octopussy yet.
Tracking mentions began in Dec 2020.
pgbadger
-
Site down due hosted on digitalocean
It might also help to use pgbadger or something similar to process your postgres logs and see whether some event is aligned with your outages.
-
SQL: 2023 Has Been Released
Interestingly, when a place does get to the point where the single instance has capacity issues (after upgrading to EPYC and lots of flash drives) then other non-obvious stuff shows up too.
For example, at one place just over a year ago they were well into this territory. One of weird problems for them was with pgBadger's memory usage (https://github.com/darold/pgbadger). That's written in perl, which doesn't seem to go garbage collection well. So even on a reporting node with a few hundred GB's of ram, it could take more than 24 hours to do a "monthly" reporting run.
There wasn't a solution in place at the time I left, so they're probably still having the issue... ;)
- Moving from Oracle to Postgres, what should I know?
-
What are the top 3 most useful things that you have hosted over the years?
First of all I used a profiler (pgbadger and netdata) to figure out where the lags were coming from. I then tried the usual stuff (increasing shared_buffers, max_wal_size, min_wal_size from their ultra low defaults), but the biggest performance gain came from moving the database from eMMC to a mechanical hard drive :-D
-
Best way to find queries that might benefit from indexes.
Look into PgBadger (a log parser/analyser): https://github.com/darold/pgbadger
What are some alternatives?
graylog - Free and open log management
pgaudit_analyze - PostgreSQL Audit Analyzer
Logstash - Logstash - transport and process your logs, events, or other data
Mailcow - mailcow: dockerized - 🐮 + 🐋 = 💕
Elasticsearch - Free and Open, Distributed, RESTful Search Engine
minion - :octopus: Perl high performance job queue
Flume - Mirror of Apache Flume
postgresqltuner - Simple script to analyse your PostgreSQL database configuration, and give tuning advice
Sending your docker logs - Sending logs from docker containers to Logit.io
apache2buddy - apache2buddy
Fluentd - Fluentd: Unified Logging Layer (project under CNCF)
pg_wait_sampling - Sampling based statistics of wait events