Performance

Monitoring your deployment

Databases for EnterpriseDB deployments offer an integration with the IBM Cloud® Monitoring service for basic monitoring of resource usage on your deployment. Many of the available metrics, like disk usage and IOPS, are presented to help you configure autoscaling on your deployment. Observing trends in your usage and configuring the autoscaling to respond to them can help alleviate performance problems before your databases become unstable due to resource exhaustion.

Disk IOPS

The number of Input-Output Operations Per Second (IOPS) is limited by the type of storage volume. Storage volumes for Databases for EnterpriseDB deployments are provisioned on Block Storage Endurance Volumes in the 10 IOPS per GB tier. If your operational load saturates or exceeds the IOPS limit, database requests and operations are delayed until the disk can catch up. Extended periods of heavy-load can cause your deployment to be unable to process queries and become effectively unavailable. If you experience delayed responses and failing operations, you might be exceeding the disk's IOPS limit. You can increase the number IOPS available to your deployment by increasing disk space.

Memory Usage

Databases for EnterpriseDB deployment's memory settings are auto-tuned based on the deployment's total memory. Specifically, work_mem, maintenance_work_mem, and effective_cache_size are set on provision, restore, or scale.

You can set the amount of memory that is dedicated to the databases' shared buffer pool by adjusting the shared_buffers in your Databases for EnterpriseDB configuration. The recommended value to use is 25% of the deployment's total memory. Allocating too much to the shared buffer pool can starve the system of memory for other purposes and hurts performance (or crash the database). The maximum size of the shared buffer pool is 8 GB, based on recommendations of the PostgreSQL community.

Allocating larger amounts of memory (outside of the shared buffer pool) to your deployment still benefits performance. For example, Databases for EnterpriseDB fills memory with cached disk pages for performance. You don't have to allocate memory to Databases for EnterpriseDB directly for Databases for EnterpriseDB to use it.

Connection Limits

Databases for EnterpriseDB sets the maximum number of connections to your database to 115. 15 connections are reserved for the superuser to maintain the state and integrity of your database, and 100 connections are available for you and your applications. After the connection limit has been reached, any attempts at starting a new connection results in an error. To prevent overwhelming your deployment with connections, use connection pooling, or scale your deployment and increase its connection limit. For more information, see the Managing Databases for EnterpriseDB Connections page.