비용이 많이 드는 RDS 인스턴스가 있습니다. Amazon의 계정 활동에서 지난 7 일 동안 인스턴스에 약 800,000,000 개의 IO 요청이 있었음을 알 수 있습니다.
약간의 관점을 제시하기 위해 내 앱은 하루에 약 6,000 회의 고유 방문 횟수 만 가져 오지만 데이터베이스 연결이 많지 않습니다.
그렇다면 IO 요청은 정확히 무엇이며 왜 그 수가 그렇게 높지 않을까요? 필요한 경우 해당 비용을 줄이기 위해 내 앱에 필요한 모든 것을 기꺼이 수행하지만 실제로 무슨 일이 일어나고 있는지 잘 모르겠습니다.
당신의 생각에 감사드립니다.
답변:
아, 아마존 웹 서비스. 가장 큰 머니 싱크 중 하나입니다. 아주 좋지만 항상 싼 것은 아닙니다. 실제로 거의 저렴하지 않으며 항상 비용을 추정하기가 어렵습니다.
IO 요청은 디스크 작업입니다. 읽기 또는 쓰기는 기본적으로 시스템에서 얼마나 많은 데이터를 가져 오는지에 대한 책임이 있습니다. 미쳤다.
iostat를 보면 IO 요청을 추정 할 수 있습니다.
7 일 만에 800,000,000 개의 IO 요청. ~ = 1300 IOPS입니다. 와. 그것은 사악한 성능입니다.
예를 들어, 중간 크기의 웹 사이트 데이터베이스는 크기가 100GB 일 수 있으며 한 달 동안 초당 평균 100 개의 I / O를 기대합니다. 이는 스토리지 비용 (100GB x $ 0.10 / 월)에서 월 10 달러, 요청 비용에서 월 $ 26 (약 260 만 초 / 월 x 초당 100 I / O * 백만 I / O 당 $ 0.10)로 해석됩니다.
에서 http://aws.amazon.com/ebs/ 페이지 내리막 길의 90 %에 대한
비용이 많이 드는 것을 줄이려면 RDS가 실제로 응용 프로그램 및 프로젝트 예산에 가장 적합한 지 살펴볼 때입니다.
하루에 6k 회만 방문하는 경우 전용 서버 (바람직하게는 em 2 개, DB 1 개, 웹 서비스 1 개)로 비용과 성능을 향상시킬 수 있습니다. 응용 프로그램에 대해 너무 많이 말하지 않았으므로 실제로 전화를 걸기가 더 어렵습니다.
비용이 많이 드는 RDS 인스턴스가 있습니다.
"클라우드 서비스"가 물건 비용으로 돈을 벌 수 있다는 의미는 아닙니다. 기본적으로 I / O 요청은 디스크에서 가져와야하는 모든 것 (예 : 데이터베이스 또는 색인 페이지)입니다. 전체 테이블 스캔을 사용하는 큰 데이터베이스 및 쿼리가있는 경우 이는 놀라운 일이 아닙니다. " 인덱싱 되지 않은"쿼리를 MySQL 느린 로그에 기록하는 옵션을 활성화 하고 적절한 열에 대한 인덱스를 추가하여 필터링을 위해 인덱싱 되지 않은 열을 사용하는 쿼리를 찾는 것이 좋습니다 . 구성 파일을 직접 편집 할 수있는 옵션이 없으므로 RDS 매개 변수 그룹 구성 을 사용하여 로그 항목에 log-queries-not-using-indexes대한 mysql.slow_log테이블 을 설정 하고 쿼리하십시오 .
또한 일반적인 성능 분석을 위해 AWS 인스턴스에서 데이터베이스 인스턴스에 대해 MySQL 튜닝 입문서 스크립트 를 실행하여 더 큰 인스턴스가 캐싱에 사용할 수있는 더 많은 양의 메모리로 인해 문제를 해결하는 데 도움이되는지 확인하여 디스크의로드를 완화하십시오. 이 스크립트는 여러 구성 매개 변수 및 성능 카운터를 평가하여 가능한 병목 현상에 대한 정보를 제공하고 일반적인 권장 사항을 제공합니다.
&자사의 코드를 분명히 아무도 그것을 프로파일 없었다..)