Aurora MySQL5.x -> Aurora MySQL8.x 업그레이드 후 자원 사용량 이슈 및 성능관련한 이슈가 발생합니다.
MySQL 5.7에서 8.0으로 업그레이드할 때 기본 설정 및 동작 변경으로 인해 성능 저하가 발생하는 것이 일반적입니다.
이미 알고 계시겠지만 MySQL 5.7과 MySQL 8.0 사이에는 상당한 차이가 있습니다.
업그레이드 간에 기본 데이터는 동일하더라도 쿼리 실행에 영향을 미치고 결과적으로 잠금 또는 대기 시간이 발생할 수 있는 엔진 설계에는 상당한 차이가 있습니다.
예를 들어 MySQL 5.7은 8.0에서는 달라지는 최적화 프로그램의 선택 사항을 사용하여 쿼리를 실행하기로 결정합니다.
또한, 프로덕션 환경에서 마이그레이션 또는 업그레이드하기 전에 수행해야 하는 가장 일반적인 권장 단계/작업은 다음과 같습니다.
- 쿼리가 힌트(강제 인덱스)를 사용하는 경우 힌트를 제거하고 성능을 확인하는 것이 좋습니다.
- EXPLAIN을 실행하고 인덱스가 사용되고 있는지 확인합니다(테이블 힌트 없이).
자세한 내용은 [+]https://mariadb.com/kb/en/show-explain/을 참조하세요. - 누락된 인덱스를 만듭니다.
- 필요한 경우 복잡한 쿼리를 리팩토링합니다.
- 쿼리가 대부분의 시간을 소비하는 위치를 확인하도록 프로파일링 설정
자세한 내용은 [+]https://dev.mysql.com/doc/refman/8.0/en/show-profile.html을 참조하세요. - 오래된 통계가 있는 테이블을 분석합니다.
자세한 내용은 [+]https://dev.mysql.com/doc/refman/8.0/en/analyze-table.html을 참조하세요. - SHOW TABLE STATUS\G를 실행합니다. 식별된 쿼리의 일부인 테이블의 경우.
자세한 내용은 [+]https://dev.mysql.com/doc/refman/8.0/en/show-table-status.html을 참조하세요. - SHOW FULL PROCESSLIST\G 및 SHOW ENGINE INNODB STATUS\G를 실행하여 이 샘플 쿼리의 성능에 영향을 미치는 다른 쿼리/세션이 있는지 확인합니다.
때로는 서버의 리소스가 사용량이 많으면 서버의 다른 모든 작업에 영향을 미치고 쿼리에도 영향을 미칩니다.
쿼리가 실행될 때 주기적으로 정보를 캡처하거나 적시에 캡처하도록 cron 작업을 설정하면 도움이 될 것입니다.
기록 목록 길이가 긴지 모니터링하는 것이 매우 중요합니다(확실한 숫자는 없지만 물론 수십만이면 좋지 않음).
쿼리 성능, 특히 DML 또는 SELECT에 영향을 미칠 수 있습니다.
기록 목록 길이는 purge_lag 값을 나타내며, 거대한 연결 목록을 순회해야 하므로 작업에 영향을 줍니다.
서버의 메모리에 버퍼 풀 공간이 부족하면 상황이 더욱 악화됩니다.
버퍼 풀 통계 및 HLL을 모니터링하려면 SHOW ENGINE INNODB STATUS를 사용하십시오.
※스마일샤크가 제공하는 모든 콘텐츠는 관련 법의 보호를 받습니다. 스마일샤크 콘텐츠를 사전허가 없이 무단으로 복사·배포·판매·전시·개작할 경우 민·형사상 책임이 따를 수 있습니다. 콘텐츠 사용과 관련해 궁금한 점이 있으면 전화(☎: 070-4369-2028) 또는 이메일(contact@smileshark.kr)로 문의하기 바랍니다
댓글
댓글 0개
댓글을 남기려면 로그인하세요.