【Azure Database for PostgreSQL】予期しないメモリ使用量の増加について

Oury Ba-MSFT

Thank you very much for your investigation.

I now understand that the current memory usage is influenced by the "shared_buffers" setting.

Around February to March of this year, we changed the value of "shared_buffers" from 4GB to 8GB, but it seems the change had not been applied until now.

Is there a way to apply the "shared_buffers" setting immediately after making such a change? (Is there a way to eliminate memory fragmentation and enable huge_pages immediately?)

TM107710 Thank you for getting back.

Although you changed shared_buffers from 4 GB to 8 GB earlier this year, PostgreSQL only successfully allocated huge pages during the most recent restart. This delay was due to memory fragmentation, which previously prevented the system from finding enough contiguous memory blocks to allocate huge pages

Can You Apply shared_buffers Immediately?

You cannot apply shared_buffers immediately without a restart. This parameter is classified as static, meaning it requires a full server restart to take effect.

Oury Ba-MSFT

Thank you very much for your response to my questions.

I have two final points I would like to confirm:

①If a full server reboot is required, would it be necessary to request support to perform it?

②I understand that the sudden increase in memory usage was due to "huge_pages" being enabled.

Why did "huge_pages" suddenly become active around 3:30 AM on July 10?

Thanks for your questions TM107710

The behavior you're observing—where memory usage increased after a restart due to huge pages being activated—is documented in the official Microsoft Learn article at https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/server-parameters-table-resource-usage-memory?pivots=postgresql-16

The activation of huge_pages at that specific time was triggered by a server restart—most likely due to platform-initiated maintenance or automated patching by Azure.

Your server was already configured with:

huge_pages = try

shared_buffers = 8GB on a 16GB instance

Before July 10, PostgreSQL attempted to allocate huge pages at startup but failed silently (due to memory fragmentation or lack of contiguous memory). It fell back to regular pages, so memory usage remained low (~25%).

At 3:30 AM on July 10:

• A restart occurred—either due to:
  • Azure’s automated maintenance window
  • A platform patch or failover
  • A manual restart (less likely if you didn’t initiate it)
• During this restart, the OS had sufficient contiguous memory available.

PostgreSQL successfully allocated huge pages for the first time.

Memory usage jumped to ~65% immediately after the restart.

This is expected behavior when huge pages are successfully allocated—they reserve large memory blocks upfront.

Best practices for managing memory consumption

Avoid disabling huge_pages unless memory pressure is critical doing so may reduce performance

https://docs.azure.cn/en-us/postgresql/flexible-server/how-to-high-memory-utilization

Oury Ba-MSFT

Thank you for your response to the additional questions.

Regarding Question ②:

I understand that the server restart on July 10 was caused by a background update initiated by Azure.

Was there any prior notification regarding this restart?

Regarding Question ①:

If, after modifying the "shared_buffers" setting, a restart is performed via the Azure Portal but no change in memory usage is observed,

would it be appropriate to request a full server restart through Azure Support in that case?