결론부터 말하자면 RDS 의 cpu 가 예상과 다르게 100% 를 찍는다면 빨리 slow query 를 찾아보세요.

며칠 동안 불규칙 적으로 발생한 5분 정도 짜리의 cpu 과부하를 찾아내는 것은 쉽지 않았습니다.

RDS 에서 생성된 slow_query.log 파일에는 로그 flush 메시지 밖에 없었으니까요.

특별히 높지 않은 커넥션 수...

lock 이 걸렸는지, slow query 가 걸렸는지 5분 정도만에 cpu 점유율이 다시 안정을 되찾는...

밤이고 낮이고 심심할 때 가끔씩 찾아오는 과부하라...

그 시간대에 발생된 query 를 5 대가 넘는 서버에서 모두 뽑기엔, 아니 뽑는다 해도 이 중 무엇이 문제인지 알 수가 없다는...

람다에서 주기적으로 유입되는 데이터를 의심했지만, 시간대가 맞기도 하고 안맞기도 하고...

processlist query 를 1분마다 날리면서 lock 걸린 query 를 찾아야 하는 것인가...

일단 slow query 를 좀 봐야겠다는 생각에 20초 짜리 query 를 날렸지만, 이마저 slow_query.log 파일은 응답하지 않았습니다.

결국 고객센터에 징징거리기 시작했더니, 해결책을 알려줬습니다.

log_output 이 default 로 table 로 되어 있어서 slow query 가 테이블에 들어가 있다는...

EC~! 근데 왜 slow_query 파일이 생성되서 사람 민망하게 만드는 거냐고!!

화는 잠시 접어두고 결국 slow query 를 찾아 잘못된 인덱스를 수정하고 cpu 를 잠재웠습니다.

하필 중요한 검색 쪽이 ㅡㅡ;;

그럼 그렇지. 이 많은 query 들이 slow query 하나 없이 잘 돌아가고 있다고 생각한 나는 용자.

참고로 알아두면 좋을 Parameter Groups 를 적어 봅니다.

• slow_query_log : 1 (slow query 사용)
• long_query_time : 2 (slow query 제한, default 10 초)
• log_queries_not_using_indexes : 1 (인덱스 타지 않는 query 기록)
• log_output : table (로그 출력 table / file)