[Aurora MySQL]갑작스러운 CPU 상승, 롤백 세그먼트 이력에 대한 해결과 성능 튜닝

갑작스럽게 CPU가 평소보다 높아져 알람이 발생하였다.

Aurora Mysql 에서 cpu 가 갑작스럽게 높아졌을 때 가장 먼저 확인해 볼 사항은 RollbackSegmentHistoryListLength 이다.

 

---

RollbackSegmentHistoryListLength 란?

RollbackSegmentHistory 는 데이터베이스의 롤백 세그먼트와 관련된 이력 정보를 추적하는 데 사용된다. 롤백 세그먼트는 트랜잭션의 변경 사항을 롤백하거나 복구하기 위해 사용되는 공간이다.

 

RollbackSegmentHistoryListLength 확인 방법

AWS 콘솔 > 데이터베이스 > 해당 DB > 모니터링 > RollbackSegmentHistoryListLength

 

 

 

RollbackSegmentHistoryListLength 증가 원인

1. Replication Delay:
   • Aurora MySQL에서는 Aurora Replicas 간에 복제가 이루어진다. Replication이 따라잡지 못하고 지연되면 rseg가 증가할 수 있다.
   • 해결 방법: Replication 상태를 확인하고 지연되고 있는 경우에는 복제 지연 원인을 식별하고 조치를 취해야 한다. Aurora 콘솔이나 CloudWatch 등의 도구를 사용하여 Replication 상태를 모니터링할 수 있다.
2. Heavy Write Workload:
   • Write-intensive 작업이 높은 부하를 유발할 수 있다.
   • 해결 방법: 쿼리를 최적화하고 적절한 인덱스를 추가하여 쓰기 성능을 향상시킨다.
3. Long-running Transactions:
   • 트랜잭션이 오랜 시간동안 열려 있는 경우 rseg가 증가할 수 있다.
   • 해결 방법: 지속 시간이 긴 트랜잭션을 확인하여 조치한다.
4. Aurora Version:
   • Aurora MySQL 엔진의 버전이 오래되거나 버그가 있는 경우, 해당 문제로 인해 rseg가 증가할 수 있다.
   • 해결 방법: Aurora MySQL 엔진을 최신 버전으로 업데이트한다.

 

 

---

해결

Long-running Transaction을 확인한다.

SELECT * 
FROM information_schema.processlist 
order by time desc;

result >>
+----+-------+-----------------+---------+---------+------+--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| ID | USER  | HOST            | DB      | COMMAND | TIME | STATE        | INFO                                                                                                                                                                                                                                                        |
+----+-------+-----------------+---------+---------+------+--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 1  | user1 | 192.168.1.101   | mydb    | Query   | 21723| Sending data | SELECT * FROM ...                                                                                                                                                                                                                                                      |
| 2  | user2 | 192.168.1.102   | mydb    | Query   | 120  | executing    | SELECT * FROM my_table WHERE condition;                                                                                                                                                                                                                    |
| 3  | user3 | 192.168.1.103   | mydb    | Sleep   | 10   |              | NULL                                                                                                                                                                                                                                                        |
+----+-------+-----------------+---------+---------+------+--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

 

확인 결과 비정상적으로 오래 지속되고 있는 세션이 확인되었다. time은 초 단위로, 환산하면 약 5시간 반 정도 세션이 지속된 것으로 보인다. cpu가 튀기 시작한 시점과 일치한다.

 

해당 세션에 대해 담당자와 확인을 하고 kill을 진행하였다.

 

 

mysql kill session

CALL mysql.rds_kill([ID]); -- processlist 의 id값을 넣는다.

 

 

결과

rollbackSegmentHistoryListLength 지표는 해당 세션을 kill 함과 동시에 정상 범위로 돌아왔지만 CPU는 정상 범주로 돌아오는데까지 3-40분정도 소요되었다. 세션 kill 후에 세션이 실제로 정리되는데 까지 시간이 걸리는 것으로 보인다.