지난 며칠 동안 우리는 IOPS의 상한선에 도달했습니다. 우리는 몇 차례 더 많은 IOPS를 프로비저닝했습니다. 1250 -> 2500 -> 4500. 각 단계에서 읽기와 쓰기 사이에 최대치로 사용 가능한 모든 IOPS를 사용하고 있음을 빠르게 확인했습니다.
마침내 오늘 아침 또 다른 대규모 고객이 참여했고 CPU, 메모리, IOPS가 최대치를 기록했습니다. 나는 시스템을 계속 실행하기 위해 더 큰 데이터베이스 유형을 제공하기로 결정했습니다. db.m5.xlarge에서 db.m5.2xlarge로 이동했습니다. 또한 업그레이드를 통해 IOP를 8000으로 높였습니다.
이제 CPU는 그에 비해 성능이 저하되고 IOPS는 거의 0입니다. 앱은 반응하는 것처럼 보이지만 작업 대기열이 상당히 느립니다.
코드는 변경되지 않았으며 데이터베이스만 변경되었습니다. 내가 무엇을 놓치고 있나요? RDS가 올바르게 보고하지 않습니까?
지난 3일 동안 읽기 IOPS가 급증한 것을 확인할 수 있으며 이는 더 높은 IOPS 조항과 일치합니다.
답변1
아마도 절벽에서 떨어진 쿼리가 있을 것입니다. (좋은 설명 감사드립니다. 그럴듯한 설명은 이렇습니다.)
예. 쿼리가 7천만 개의 행이 있는 7GB 테이블(유용한 인덱스 등 없음)을 스캔한다고 가정해 보겠습니다.
사례 1: RAM = 8GB; innodb_buffer_pool_size= 6GB. 쿼리는 스캔을 완료하기 위해 모든 것을 캐시에서 꺼냅니다. 이를 위해서는 견고한 I/O가 필요합니다. 다른 모든 쿼리도 영향을 받습니다. 해당 데이터도 RAM에서 빠져나옵니다.
사례 2: RAM = 16GB; innodb_buffer_pool_size= 12GB. 첫 번째 스캔에서는 전체 테이블을 캐시에 로드합니다. 이후에 해당 쿼리를 실행할 때는 I/O를 수행할 필요가 없습니다. 캐시에 대한 경합이 없기 때문에 다른 쿼리도 더 빠르게 실행됩니다.
두 경우 모두 7천만 행을 모두 살펴보는 데 CPU가 많이 소모될 수 있습니다.
계획 A: 더 많은 RAM, CPU 및 불필요한 IOP를 확보하는 데 비용을 지출합니다.
계획 B: 매우 불쾌한 쿼리를 찾아서 이를 최적화하는 데 도움을 요청합니다. 그런 다음 더 저렴한 VM으로 돌아갈 수 있습니다.
쿼리와 SHOW CREATE TABLE관련된 테이블을 제공해 주세요. 해결책은 복합 인덱스를 추가하거나 쿼리를 다시 작성하는 것만큼 간단할 수 있습니다.
답변2
여기서 핵심은 아무것도 하지 않는 것이었습니다. '마법처럼' 우리의 CPU는 내가 예상했던 위치로 정규화되었습니다. 좋은 소식은 쿼리에서 몇 가지 아픈 지점, 몇 가지 과도한 잠금, 그리고 InnoDB/RDS/MySQL 튜닝에 대한 엄청난 이해를 확인했다는 것입니다.
아마도 RDS가 인덱스를 천천히 최적화하거나 완전히 이해하지 못하는 것일 수도 있지만 이제 대기 시간은 놀랍습니다. 처리량과 사용량은 4개 코어와 2배 메모리로 예상했던 것과 정확히 일치합니다.
