Unable to stop/restart PostgreSQL Flexible Server (CPU at 100%)

Hi @Gia

The server's resource utilization is high, indicating a heavy workload. Please review the long-running transactions and terminate any that can be stopped to reduce resource usage. Once resources are stabilized, you may retry restarting the server if necessary.

If the issue persists, you may need to open a support request to check the server's health and perform a backend restart if needed.

Thank You!

Hi @Gia,

I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this! Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to accept the answer.

Issue:

I have a Azure Database for PostgreSQL - Flexible Server with its CPU usage at 100% for the past weeks... In the same period, the storage usage has also significantly increased to 80-90% of its 64 GB capacity.

I am unable to stop/restart the server via Azure Portal and CLI.

[ ~ ]$ az postgres flexible-server stop --name serverName --resource-group resourceGroupName Server will be automatically started after 7 days if you do not perform a manual start operation (InternalServerError) An unexpected error occured while processing the request. Tracking ID: '{someGUID}' Code: InternalServerError Message: An unexpected error occured while processing the request. Tracking ID: '{someGUID}'

What could be causing the issue?

I looked on pgAdmin and the database size is about 6 GB. So, what could be using > 80% of the storage?

Solution:

I ended up opening a ticket with MS Azure technical support. We upgraded the VM's CPU vCores and storage space. I was then able to restart the PostgreSQL server.

Issues were resolved. I will continue to monitor the server and eventually downgrade the vCores since the DB, and customer's workload, don't need that much computing power.

The actual DB didn't grow in size, so something was going on with the VM. We think the issues might had been caused by a failure of our in-house DB backup process which triggers every Saturday, and may explain the sudden CPU/storage increase on December 21.

If I missed anything please let me know and I'd be happy to add it to my answer, or feel free to comment below with any additional information.

Hope this helps. Do let us know if you have any further queries.

If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.