| Aurora MySql 에서 적용할 수 없는 파라미터 및 상태 변수(오로라 사용 설명서 ) (0) | 2021.02.09 |
|---|---|
| percona tookit downloads (0) | 2021.01.24 |
| Max Connections 고려사항 (0) | 2020.12.30 |
| Using Index Condition 설명 (0) | 2020.11.28 |
| Percona Toolkit 사용 (0) | 2020.11.27 |
MySQL 서버의 Max Connection 고려사항
1. Connection Usage(%)
= Threads_connected / max_connection *100
2.오전 /오후 , 주중/주말 비교 확인
, was 커넥션풀 최대동시커넥션 개수보다 크게
max connections 설정 이후 필수 모니터링
연결취소율(%) = Aborted_clients * 100 / Connections
0% 에 가까울 수록 좋음
| percona tookit downloads (0) | 2021.01.24 |
|---|---|
| pt-query-digest를 사용하여 Amazon Aurora 느린 로그 분석 (0) | 2021.01.23 |
| Using Index Condition 설명 (0) | 2020.11.28 |
| Percona Toolkit 사용 (0) | 2020.11.27 |
| User CPU 사용률 100% 원인 - 동일한쿼리 동시다발적으로 실행 (0) | 2020.11.25 |
실행계획(EXPLAIN)의 Extra 칼럼에 "Using Index Condition"이라고 표시되는 경우가 있다.
이는 WHERE 절의 인덱스를 이용한 조건(인덱스를 사용한 조건이어야 함)에 체크 조건이 있을 경우 체크 조건 처리를 스토리지 엔진이 하도록 전달하는 것이다.
Mysql은 Mysql 엔진과 스토리지 엔진으로 구성되어 있는데, 범위를 제한하는 조건은 스토리지 엔진에서 인덱스로 데이터를 찾으면서 사용한다. 그런 다음 찾은 데이터를 Mysql 엔진에게 넘긴다.
Mysql 엔진은 범위를 제한하지 못하는 체크 조건을 처리하게 된다. 이 체크 조건에 부합하지 않은 레코드는 버리게 된다.
Mysql 엔진과 스토리지 엔진은 tcp 통신을 하기 때문에 체크 조건에 맞지 레코드를 전달하는 것은 낭비다.
이렇게 스토리지 엔진이 체크 조건까지 처리하도록 최적화가 되었고, "Condition push down"이라고 불린다. 이게 InnoDB에 5.1버전부터 들어갔는데, extra 칼럼에 Using Index Condition이라고 표시된 건 5.6버전(https://dev.mysql.com/doc/refman/5.6/en/index-condition-pushdown-optimization.html)부터이다.
| pt-query-digest를 사용하여 Amazon Aurora 느린 로그 분석 (0) | 2021.01.23 |
|---|---|
| Max Connections 고려사항 (0) | 2020.12.30 |
| Percona Toolkit 사용 (0) | 2020.11.27 |
| User CPU 사용률 100% 원인 - 동일한쿼리 동시다발적으로 실행 (0) | 2020.11.25 |
| dbstar (0) | 2020.11.25 |
Percona Toolkit 사용
pt-query-digest
슬로우쿼리의 요약 정보를 보여줍니다. 사용법은 아래 링크에서 참고 가능합니다.
https://blog.naver.com/sory1008/220940827130
pt-summary
하드웨어 스펙을 요약해 보여 줍니다.
https://blog.naver.com/sory1008/221173659939
pt-online-schema-change
| Max Connections 고려사항 (0) | 2020.12.30 |
|---|---|
| Using Index Condition 설명 (0) | 2020.11.28 |
| User CPU 사용률 100% 원인 - 동일한쿼리 동시다발적으로 실행 (0) | 2020.11.25 |
| dbstar (0) | 2020.11.25 |
| mysql8.0.22 release (0) | 2020.11.25 |
innodb_sync_spin_loops : 스레드가 일시 중단되기 전에 스레드가 InnoDB 뮤텍스가 해제되기를 기다리는 횟수.
(기본값 30.)
innodb_sync_spin_loops 값에 따라 User CPU 사용률의 변화가 큼
nnodb_sync_spin_loops 값에 따라 User CPU 사용률의 변화가큼
Sys CPU 사용률과 Idle CPU 사용률을 보았을 때 값이 10일 때가 가장 적절해 보인다고 필자는 이야기함
innodb_spin_wait_delay : 스핀 잠금을위한 폴링 사이의 최대 지연. (기본값 6.)
CPU 사용률이 높은 상황에선 innodb_spin_wait_delay 값을 줄여도 크게 영향을 미치진 않음.
극단적으로 값을 0으로 설정해야 User CPU 사용이 줄어듦
CPU가 어느정도 여유가 있는 상태에서 innodb_spin_wait_delay 값을 조정하는경우는
어느정도 영향력을 가짐
위 내용은 아래 블로그를 참고함
| Using Index Condition 설명 (0) | 2020.11.28 |
|---|---|
| Percona Toolkit 사용 (0) | 2020.11.27 |
| dbstar (0) | 2020.11.25 |
| mysql8.0.22 release (0) | 2020.11.25 |
| MySQL에서 DB 부하에 대한 최적화 방법(Aurora) (0) | 2020.11.22 |
https://stardba.net/chan/mysql-innodb-as-cache-server-monitoring/
| Percona Toolkit 사용 (0) | 2020.11.27 |
|---|---|
| User CPU 사용률 100% 원인 - 동일한쿼리 동시다발적으로 실행 (0) | 2020.11.25 |
| mysql8.0.22 release (0) | 2020.11.25 |
| MySQL에서 DB 부하에 대한 최적화 방법(Aurora) (0) | 2020.11.22 |
| 파일 입출력, 디스크립터 설명 (0) | 2020.11.22 |
https://mysqlserverteam.com/the-mysql-8-0-22-maintenance-release-is-generally-available/
| User CPU 사용률 100% 원인 - 동일한쿼리 동시다발적으로 실행 (0) | 2020.11.25 |
|---|---|
| dbstar (0) | 2020.11.25 |
| MySQL에서 DB 부하에 대한 최적화 방법(Aurora) (0) | 2020.11.22 |
| 파일 입출력, 디스크립터 설명 (0) | 2020.11.22 |
| 통계의정확성을 높이자. (0) | 2020.11.21 |
| dbstar (0) | 2020.11.25 |
|---|---|
| mysql8.0.22 release (0) | 2020.11.25 |
| 파일 입출력, 디스크립터 설명 (0) | 2020.11.22 |
| 통계의정확성을 높이자. (0) | 2020.11.21 |
| 오로라 성능관련 (0) | 2020.11.20 |
| mysql8.0.22 release (0) | 2020.11.25 |
|---|---|
| MySQL에서 DB 부하에 대한 최적화 방법(Aurora) (0) | 2020.11.22 |
| 통계의정확성을 높이자. (0) | 2020.11.21 |
| 오로라 성능관련 (0) | 2020.11.20 |
| Sysbench 1.1을 사용하여 MySQL 5.7 벤치마킹 (0) | 2020.10.19 |
통계의 정확성을 개선할 수 있는 두가지 매커니즘.
대규모 테이블의 경우 정확한 통계가 쿼리옵티마이저에게 매우 중요하다.
정확한 통계는 쿼리옵티마이저가 올바른 카디널리티로 가장 선별된 인덱스를 사용하도록 지원하므로 쿼리 성능이 향상된다.
기본적으로 10%이상의 로우 변경이 발생해야 갱신되는데 매우 큰 테이블의경우 자주발생하지 않아
통계의 정확도가 감소할 수 있다.
정보스키마를 사용하며 관련테이블에 대한 테이블 및 인덱스통계의 경과시간을 모니터링한 후
analyze table 실행.
Auroal MySQL의 경우 임의 인덱스 페이지 샘플링 개수는 20개이다.
하지만 매우 큰 테이블이나 균일하지않은 컬럼이 포함되는 테이블인 경우 20개는 충분하지 않을 수 있다.
샘플링되는 페이지수를 늘리면 정확도가 증가함(증가시킬수록 통계를 계산하는데 걸리는 시간도 늘어남)
innodb_stat_persistent_sample_pages 256
-> 통계가 디스크에 유지되는경우 샘플링된 페이지에대한 글로벌 파라미터(테이블별로 구성가능)
innodb_stat_transient_sample_pages 256
-> 위와 비슷하지만 통계가 디스크에 유지되지 않는 경우 사용되는 글로벌파라미터
| MySQL에서 DB 부하에 대한 최적화 방법(Aurora) (0) | 2020.11.22 |
|---|---|
| 파일 입출력, 디스크립터 설명 (0) | 2020.11.22 |
| 오로라 성능관련 (0) | 2020.11.20 |
| Sysbench 1.1을 사용하여 MySQL 5.7 벤치마킹 (0) | 2020.10.19 |
| 마리아DB 시스템변수 / 상태변수 (0) | 2020.09.27 |