We sometimes see customers asking questions related to a discrepancy between the server storage usage and their expectations on the actual data usage. In this blog we will go through how to investigate storage consumption for Azure Database for PostgreSQL.
In this section, I am listing down some thoughtful insights and recommendations to breakdown the storage usage to some extent.
SELECT pg_database.datname as "database_name", pg_database_size(pg_database.datname)/1024/1024 AS size_in_mb FROM pg_database where datname not like ('%azure%') ORDER by size_in_mb DESC;
- Check out the tables' vacuum status, if dead rows are being vacuumed using pg_stat_user_tables
SELECT relname,n_dead_tup, n_tup_del,n_tup_upd, last_vacuum, last_autovacuum,last_analyze,last_autoanalyze FROM pg_stat_user_tables;
- You can get each database temporary files and size using view pg_stat_database
SELECT * FROM pg_stat_database;
- A quick look at view pg_stat_archiver can be a good idea, the view is showing statistics about the WAL archiver process's activity.
select * from pg_stat_archiver;
- You can get the difference b/w the current WAL and the last archived one, taking into account that each WAL file has size of 16MB.
('x'||substring(last_archived_wal,9,8))::bit(32)::int*256 - ('x'||substring(last_archived_wal,17))::bit(32)::int as diff
3) Examine the following server parameters which might contribute into the storage usage growth
The general advice that you should be careful with the verbose logging, More information can be found in my colleague blog How to configure Postgres log settings - Microsoft Tech Community
It worth to mention that you can set the retention period for this short-term log storage using the log_retention_period parameter. The default value is 3 days; the maximum value is 7 days. The short-term storage location can hold up to 1 GB of log files. However, after 1 GB, the oldest files, regardless of retention period, will be deleted to make room for new logs.
For longer term retention and larger storage, consider using Azure diagnostic settings. see the Azure PostgresSQL logging documentation for more information.
4) Logical Decoding
Unnecessary PostgreSQL Logical decoding replication slots can have high impact on the server availability and storage consumption, replication slots hold on to Postgres WAL logs and relevant system catalogs until changes have been read by a consumer. in case this is failing to do so, the unconsumed logs will pile up and fill the server storage.
Therefore, it is critical that logical replication slots are consumed continuously. If a logical replication slot is no longer used, you need to drop it immediately.
You can check replication slots on server by running:
select * from pg_replication_slots;
In case the slot is no longer needed, you can simply delete it using the command:
For more information, see Azure PostgreSQL Logical Decoding.
5) Leverage PostgreSQL VACUUM and Autovacuum to reclaim the unused space.
|Note:- VACUUM FULL, which can reclaim more space, but takes much longer and exclusively locks the table. Plus an extra disk space will be needed, since it writes a new copy of the table and doesn't release the old copy until the operation is complete.
6) Enable Storage Auto-grow and set up an alert
Last but not least, we always recommend that you enable storage auto-grow or set up an alert to notify you when your server storage is approaching the threshold so you can avoid getting into the read-only state. For more information, see the documentation on how to set up an alert.
|Note:- Keep in mind that storage can only be scaled up, not down.
I hope you find this article helpful. If you have any feedback, please do not hesitate to provide it in the comment section below.
Ahmed S. Mazrouh