Troubleshooting High CPU Usage

Description

CPU usage refers to the percentage of CPU time occupied when the system is running.

CPU usage includes the user-mode CPU time percentage and kernel-mode CPU time percentage.

User mode is the mode in which user programs are running.
Kernel mode is the mode in which OS management programs are running, including system calls, kernel threads, and interrupts.

When the CPU is full, services slow down.

Cause Analysis

There are three possible causes:

Sharp increase in active sessions
ECS underlying resource contention (non-dedicated instances)
Too many slow SQL statements

The following figure shows the troubleshooting methods for the three possible causes.

Figure 1 Cause analysis

Troubleshooting

Sharp increase in active connections
Check whether the percentage of kernel-mode CPU time is greater than 20% or whether the Active Connections metric increases sharply.
- Checking the percentage of kernel-mode CPU time
  On the Cloud Eye console, check the Kernel-mode CPU Time Percentage metric in the last one hour.
  
  If this metric is higher than 20%, there may be a large number of system calls or interrupts. In this case, a large number of processes are running in the system.
  
  When the number of active connections exceeds the instance specifications, the system continuously switches the processes running in the CPU. The kernel program switches the CPU to different address spaces. As a result, the kernel-mode CPU time percentage increases.
- Checking active connections
  On the Cloud Eye console, check whether the Active Connections metric surged at a certain time point within the last 24 hours or last 7 days.
  
  In normal cases, the number of active sessions should be twice the number of vCPUs to maximize CPU usage.
ECS resource contention (non-dedicated instances)
A rare cause for kernel-mode CPU time percentage greater than 20% is ECS resource contention. This mainly occurs in non-dedicated instances (including general-purpose and general-enhanced instances).

Generally, the kernel-mode CPU time percentage of RDS for PostgreSQL instances is lower than 10%. If this percentage is greater than 10%, check whether it is caused by ECS resource contention. Contact customer service to confirm this problem.
Too many slow SQL statements
RDS for PostgreSQL provides slow query logs. You can use these logs to locate the time-consuming SQL statements for further analysis. However, a slow SQL statement may also cause other SQL statements to run slowly, so you may find many slow SQL statements in the logs. It is hard to find the target SQL statement.

In addition to slow SQL statements, there are some simple SQL statements that may cause abruptly high CPU usage in some cases (for example, cyclic execution in a transaction or a large number of concurrent executions).

The following methods are recommended for tracing slow SQL statements:
1. Use the pg_stat_statements extension to locate the SQL statements that cause high CPU usage. For details, see pg_stat_statements.
2. Query the pg_stat_activity view to find the SQL statements that have been running for a long time.
```
SELECT  *,    
(now() - backend_start) AS proc_duration,    
(now() - xact_start) AS xact_duration,  
 (now() - query_start) AS query_duration,   
 (now() - state_change) AS state_duration  
FROM pg_stat_activity  
 WHERE pid<>pg_backend_pid()  
ORDER BY state_duration DESC limit 10;
```
3. Query the pg_stat_user_tables view to find the tables that are being scanned in full mode and the corresponding SQL statements.
```
select * from pg_stat_user_tables order by seq_tup_read desc, seq_scan desc limit 10;
```
4. Check whether there are any slow SQL statements based on the pg_stat_statements or pg_stat_activity view.
  
  The pg_stat_statements extension must be installed first.
  
  Check for slow SQL statements based on pg_stat_statements:
```
select * from pg_stat_statements where query like '%tablename%' order by shared_blks_hit + shared_blks_read desc;
```
  Check for slow SQL statements based on pg_stat_activity:
```
select 
  *, 
  (now() - backend_start) AS proc_duration,
  (now() - xact_start) AS xact_duration,
  (now() - query_start) AS query_duration,
  (now() - state_change) AS state_duration 
from pg_stat_activity
where pid<>pg_backend_pid() and query like '%tablename%'
ORDER BY state_duration DESC;
```
  These slow SQL statements are usually caused by a lack of indexes. As a result, too many buffer reads are executed, consuming a large number of CPU resources.

Solution

Sharp increase in active connections
Check whether the sharp increase in active connections is necessary for your workload. If yes, upgrade the instance specifications. If no, optimize the workload to address the sharp increase.