Database Server - AWS RDS

Synopsis

Monitored Resources

Turbonomic monitors the following resources:

• Virtual Memory (VMem)

  Virtual Memory is the measurement of memory that is in use.

• Virtual CPU (VCPU)

  Virtual CPU is the measurement of CPU that is in use.

• Storage Amount

  Storage Amount is the measurement of storage capacity that is in use.

• Storage Access (IOPS)

  Storage Access, also known as IOPS, is the per-second measurement of read and write access operations on a storage entity.

• DB Cache Hit Rate

  DB cache hit rate is the measurement of Database Server accesses that result in cache hits, measured as a percentage of hits versus total attempts. A high cache hit rate indicates efficiency.

• Connection

  Connection is the measurement of database connections utilized by applications.

Actions

Turbonomic supports the following actions:

Stop and Start Actions for Database Servers

Turbonomic supports 'parking' actions for cloud resources. These user-initiated actions stop your cloud resources for a given period of time to help you reduce your cloud expenses, and then start these resources later when you need them. You can enforce parking actions on demand, or automatically through parking schedules and policies.

For details, see Parking: Stop or Start Cloud Resources.

Scale Actions for Database Servers

To recommend accurate scaling actions, Turbonomic analyzes resource utilization percentiles and collects relevant metrics (such as connections utilization) from AWS. It also takes into consideration constraints defined in policies.

Consider the following scenarios and actions:

• To address vCPU congestion, Turbonomic can recommend scaling a Database Server to the instance type that can adequately meet demand at the lowest possible cost. If vCPU is underutilized, it can recommend scaling to a smaller instance type.

• To address IOPS congestion, Turbonomic can recommend increasing provisioned IOPS or scaling the Database Server to a different storage type. For gp2 storage, it can recommend increasing disk size to increase provisioned IOPS. After executing these actions, Turbonomic will not recommend new actions for the next six hours, in compliance with AWS's "cooldown" period for EBS storage.

• Turbonomic analyzes DB cache hit rate before making vMem scaling decisions. To perform its analysis, it collects cache hit rate metrics for Database Servers with Performance Insights enabled.

  For Database Servers with cache hit rate metrics, Turbonomic considers at least 90% cache hit rate to be optimal. This percentage value is not configurable.

  • A cache hit rate value equal to or greater than 90% indicates efficiency. For this reason, Turbonomic will not recommend an action even if vMem utilization is high. If vMem utilization is low, it will recommend scaling to a smaller instance type.

  • When the cache hit rate is below 90%, Turbonomic will also not recommend an action, provided that vMem utilization remains low. If vMem utilization is high, then it will recommend scaling to a larger instance type.

  Notes on Performance Insights and cache hit rate metrics:

  • Performance Insights is enabled by default on a majority of AWS Database Servers. In the Turbonomic user interface, you can use Search and then apply the Performance Insights filter to see which Database Servers have Performance Insights enabled.

  • If Performance Insights is disabled or is not supported for your AWS Database Server engines or regions, Turbonomic will not have cache hit rate metrics to analyze and will therefore not generate actions in direct response to vMem utilization. For a list of supported engines and regions, see this AWS page.

  • An action to scale to a different instance type in response to vCPU utilization might also include vMem changes, but vMem utilization alone (without cache hit rate metrics) will not drive actions.

Turbonomic also considers Connections utilization and capacity when making scaling decisions. It collects utilization metrics from CloudWatch and calculates capacity based on the maximum number of simultaneous connections configured for the Database Server. The maximum number varies by Database Server engine type and memory allocation, and is set in the parameter group associated with a Database Server. Turbonomic currently supports Database Servers associated with parameter groups that use default values. For example, consider a MySQL Database Server that is on a db.t3.large instance type with 8 GB (8589934592 bytes) of memory, and is associated with a parameter group that uses the default value {DBInstanceClassMemory/12582880}. In this case, Turbonomic calculates capacity as 682 connections (or {8589934592/12582880}). When Turbonomic generates an action due to vMem underutilization and sees that Connections utilization is only 15% of capacity (or roughly 100 connections), it picks a smaller instance type that is adequate for both the vMem and Connections requirements of the Database Server. For example, it could pick db.t2.small, which provides 2 GB of memory and a maximum of 170 connections.

Scale Actions in Charts

Use the Necessary Investments and Potential Savings charts to view pending Database Server actions. These charts show total monthly investments and savings, assuming you execute all the actions.

Click Show All for each chart to review and execute the actions.

The table lists all the actions that are pending for Database Servers, and the savings or investments for each action.

For details on how Turbonomic calculates savings or investments, see Estimated On-demand Costs for Cloud Database Servers.

Utilization Charts for Scale Actions

Turbonomic uses percentile calculations to measure resource utilization more accurately, and drive scaling actions that improve overall utilization and reduce costs. When you examine the details for a pending scale action on a Database Server, you will see charts that highlight utilization percentiles for a given observation period, and the projected percentiles after you execute the action.

The charts also plot daily average utilization for your reference. If you have previously executed scaling actions on the Database Server, you can see the resulting improvements in daily average utilization. Put together, these charts allow you to easily recognize utilization trends that drive Turbonomic's scaling recommendations.

You can set scaling constraints in Database Server policies to refine the percentile calculations.

For details, see Scaling Sensitivity.

Non-disruptive and Reversible Scaling Actions

Turbonomic indicates whether a pending action is non-disruptive or reversible to help you decide how to handle the action.

The following table describes the disruptiveness and reversibility of the actions that Turbonomic recommends:

You can set action acceptance modes in policies to specify the degree of automation for these actions.

Unavailable Instance Types

A scale action could fail if the target instance type is unavailable in the availability zone for some reason. Your AWS environment might show the instance type as available, but when the scaling action executes, the following error displays in AWS:

When this error occurs, Turbonomic modifies the default Database Server policy to exclude the instance type from its scaling list. When the Database Server is available again, Turbonomic adds it back to the scaling list. For details about this list, see Cloud Instance Types.