Amazon RDS Performance Insights
The course is part of these learning paths
This course explores Amazon RDS Performance Insights, a performance monitoring and tuning feature that can quickly assess the load on a database hosted inside Amazon RDS and determine when and where to take action.
In this course, you will learn what the Performance Insights service is, how it provides meaningful information database load, how to use it, and the costs and security features of the service.
If you have any feedback relating to this course, please contact us at email@example.com.
- Obtain a foundational understanding of Amazon RDS Performance Insights
- Learn how Performance Insights measures database load and adds context to AAS (Average Active Sessions)
- Learn how to use Performance Insights
- Understand how to control access to Performance Insights
- Understand the costs associated with using the service
This course is intended for both new and experienced database administrators that need to assess, understand, and optimize the load that users and applications put on an RDS database.
To get the most out of this course, you should have a basic understanding of relational databases, have created at least one RDS database instance, and a working knowledge of the AWS cloud platform.
I want to talk in detail about what RDS Performance Insights is compared to Amazon CloudWatch and RDS Enhanced Monitoring and discuss database load.
CPU utilization and database load can be related, but they are independent of each other. A database can be under high load, but have low CPU utilization. Likewise, a CPU could be experiencing high utilization levels, but be running only a few queries.
Performance Insights is a feature of Amazon RDS that provides visibility into the performance of SQL queries inside RDS databases.
More than that, it was designed to be used by people with a wide range of database management experience. Wide range includes people that are new to database administration, as well as experienced professionals.
AWS recognizes that there are IT departments that either don't have a DBA or if they do, it is somebody working part-time.
In my career, I've been an accidental DBA more than once. My primary job roles have been around systems administration, network management, and systems engineering. I understand databases and know how they work. I can create and run queries. However, I have not been very comfortable with database internals.
The last time I had the role of DBA given to me, my management did not recognize the value of having someone act as a steward or caretaker of the database. Because of this, the DBA quit and it was up to me to discover, mostly through trial and error, how to address issues.
It was a sub-optimal experience. Learning on the job using production systems is a dangerous gamble. Nobody wins.
When Amazon RDS was first introduced, Amazon Cloudwatch was used exclusively for metrics collection and CloudWatch Logs for log management. With CloudWatch, metrics are captured once every minute from the hypervisor layer. If you're familiar with monitoring EC2 instances, RDS monitoring using CloudWatch is identical to EC2's detailed monitoring. This hypervisor-based monitoring is limited to, depending on the instance type, between 15 and 18 different metrics.
CloudWatch monitoring uses a traditional approach to database monitoring. Systems and network administrators expect computing devices to behave in a certain way. More accurately, the expectation is that computing devices like databases will fail in specific ways and it is important to watch for it.
Predicting failure is difficult in the cloud because the number of ways something can fail has increased. CloudWatch metrics were not enough.
Enhanced Monitoring does metric data collection on the RDS instance. It uses a lightweight agent to get metric data from the operating system.
While CloudWatch has between 15 and 18 metrics available, depending on the database engine, Enhanced Monitoring provides over 50.
Enhanced Monitoring defaults to collecting metric data at 60-second intervals, but can be set to once per second.
Because data is being collected from the operating system, it can present a list of processes and threads like the Linux
This provides more data points than CloudWatch, but like CloudWatch, it is still collecting data about the database instance and not from the database engine.
Performance Insights collects metric data from the database engine to monitor the actual load on a database. The metrics are visible via a dashboard inside the RDS console using CloudWatch programmatically by using an API or the command line interface. The RDS Performance Insights dashboard is an interactive graph filtered by one of four attributes: SQL, user, host, and weight.
Monitoring systems like Amazon CloudWatch and Enhanced Monitoring can show 10 or more graphs of time series metrics that require end users like me to figure out what's happening inside a database. Like an episode of a television crime show or a murder mystery, I have to hunt for clues to figure out what happened, when it happened and what caused it.
Dashboard visualization such as these present facts, but it is up to me to figure out what story is being told. Sometimes playing the role of a detective not only do I have to figure out what caused the issue, I have to determine if there really was a problem at all. For example, it is easy to blame a database for performance issues, but sometimes those issues originate in an application or within the network configuration.
Performance Insights simplifies the storytelling by condensing the performance data points into a single metric that tell a very specific story. Now, instead of a murder mystery with 10 or more possible suspects each with their own motive, weapon, and possible accomplices, there is one suspect to follow. Also, because of how Performance Insights was designed, I can determine whether or not there truly was a victim. The database itself might be fine. This condensed metric measures database load and I will cover that in the next lecture.
Stephen is the AWS Certification Specialist at Cloud Academy. His content focuses heavily on topics related to certification on Amazon Web Services technologies. He loves teaching and believes that there are no shortcuts to certification but it is possible to find the right path and course of study.
Stephen has worked in IT for over 25 years in roles ranging from tech support to systems engineering. At one point, he taught computer network technology at a community college in Washington state.
Before coming to Cloud Academy, Stephen worked as a trainer and curriculum developer at AWS and brings a wealth of knowledge and experience in cloud technologies.
In his spare time, Stephen enjoys reading, sudoku, gaming, and modern square dancing.