Learning from Expertise #7: Where is my server storage taken – Azure PostgreSQL?

Learning from Expertise #7: Where is my server storage taken – Azure PostgreSQL?

This article is contributed. See the original author and article here.

Overview:


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.


 


Solution:


In this section, I am listing down some thoughtful insights and recommendations to breakdown the storage usage to some extent.


 


1) First and foremost, monitor the server storage usage using the available Azure PostgreSQL Metrics:


 



































Storage percentage Percent The percentage of storage used out of the server’s maximum.
Storage used Bytes The amount of storage in use. The storage used by the service may include the database files, transaction logs, and the server logs.
Server Log storage percent Percent The percentage of server log storage used out of the server’s maximum server log storage.
Server Log storage used Bytes The amount of server log storage in use.
Server Log storage limit Bytes The maximum server log storage for this server.
Storage limit Bytes The maximum storage for this server.

 


On Azure Portal, you can use more than one metrics as shown in below figure:


Ahmed_S_Mahmoud_0-1640951654024.png


 









Note:- Azure PostgreSQL flexible server comes with “Transaction Log Storage Used” metric, which depicts the amount of storage space used by the transaction logs.


 


2) The following queries can help you to have insights upon the database storage usage:



  • run below query to know each database size


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;

 


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:

SELECT pg_drop_replication_slot('<slot-name>');


 


For more information, see Azure PostgreSQL Logical Decoding.


 


5) Leverage PostgreSQL VACUUM and Autovacuum to reclaim the unused space.


The bloated data can be cleaned by using VACUUM to reclaim some unused space. Another thing you can optimize the autovacuum setting for better PostgreSQL performance. More information can be found at: Optimize autovacuum – Azure Database for PostgreSQL – Single Server | Microsoft Docs

 








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.


 


Ahmed_S_Mahmoud_0-1640950365554.png

 








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


Friday Five: Azure File Sync, GitHub Tips, More!

Friday Five: Azure File Sync, GitHub Tips, More!

This article is contributed. See the original author and article here.

krols.jpg


Upgrading Radial Gauge from UWP to WinUI 3


Diederik Krols lives in Antwerp, Belgium. He is a principal consultant at U2U Consult where he leads, designs and develops C# and XAML apps for the enterprise and the store. He’s a Windows Development MVP since 2014. Diederik runs the XamlBrewer blog on WordPress and the XamlBrewer repositories on GitHub. Follow him on Twitter @diederikkrols.


robbos.jpg


Maturity levels of using GitHub Actions Securely


Rob Bos is a Developer Technologies MVP and DevOps consultant from The Netherlands. Rob is typically working with anything DevOps related to improve flow. As a Global DevOps Bootcamp team member, he loves to automate large setups for the yearly event and uses any tool to get things done. For more on Rob, check out his Twitter @robbos81


hal.jpg


Surfaces of the Future Past


Hal Hostetler is an Office Apps and Services MVP who has been in the MVP program since 1996. Now retired, Hal is a Certified Professional Broadcast Engineer and remains the regional engineer for Daystar Broadcasting and a senior consultant for Roland, Schorr, & Tower. He lives in Tucson, Arizona. For more on Hal, check out his Twitter @TVWizard


silviodibenetto.jpg


AZURE FILE SYNC V14.1


Silvio Di Benedetto is founder and CEO at Inside Technologies. He is a Digital Transformation helper, and Microsoft MVP for Cloud Datacenter Management. Silvio is a speaker and author, and collaborates side-by-side with some of the most important IT companies including Microsoft, Veeam, Parallels, and 5nine to provide technical sessions. Follow him on Twitter @s_net.


tommy morgan.jpg


Weekly Update December 2021 – New UI libraries for ACS, To Do Tasks API, New SEFAUtil PowerShell, Bye Bye Command Line


Tom Morgan is a Microsoft Teams Platform developer and Microsoft MVP with more than 10 years of experience in the software development industry. For the last 8 years, Tom has worked at Modality Systems, with responsibility for delivery of the Modality Systems product portfolio. Tom is passionate about creating great software that people will find useful. He enjoys blogging and speaking about Microsoft Teams development, Office365, Bot Framework, Cognitive Services and AI, and the future of the communications industry. He blogs at thoughtstuff.co.uk and tweets at @tomorgan.