MySQL5.6 InnoDB 디스크 I / O 최적화

8.5.7 InnoDB 디스크 I / O 최적화

데이터베이스 설계 및 SQL 작업 튜닝 기술의 모범 사례에 따라도 데이터베이스가 디스크 I / O 활동이 여전히 느린 경우, 디스크 I / O에 대한 이러한 낮은 수준 기법을 조사하십시오. UNIX top 도구 또는 Windows 작업 관리자에서 워크로드의 CPU 사용률이 70 % 미만인 것으로 나타 있으면 작업은 디스크에 의존하고있을 수 있습니다.

테이블 데이터를 InnoDB 버퍼 풀에 캐시하면 디스크 I / O를 필요로하지 않고 쿼리에서 그것을 반복 할 수 있습니다. 버퍼 풀 크기는 innodb_buffer_pool_size 옵션으로 지정합니다. 이 메모리 영역은 매우 중요하기 때문에, 바쁜 데이터베이스는 종종 크기를 실제 메모리의 양의 약 80 %에 지정합니다. 자세한 내용은 섹션 8.9.1 "InnoDB 버퍼 풀" 을 참조하십시오.
GNU / Linux 및 Unix의 일부 버전에서는 유닉스 fsync() 호출 (이것은 InnoDB 가 기본으로 사용합니다)와 유사한 방식 파일을 디스크에 플래시가 놀라 울 정도로 느립니다. 데이터베이스의 쓰기 성능이 문제인 경우 innodb_flush_method 파라미터를 O_DSYNC 로 설정하고 벤치 마크를 실행합니다.
x86_64 아키텍처 (AMD Opteron)의 Solaris 10에서 InnoDB 스토리지 엔진을 사용하는 경우, InnoDB 관련 파일에 직접 I / O를 사용하여 InnoDB 의 성능 저하를 방지합니다. InnoDB 관련 파일을 저장하는 데 사용되는 UFS 파일 시스템 전체에 직접 I / O를 사용하려면 그것을 forcedirectio 옵션으로 마운트합니다. mount_ufs(1M) 를 참조하십시오. (Solaris 10 / x86_64 기본적으로이 옵션을 사용하지 않습니다). 직접 I / O를 파일 시스템 전체가 아니라 InnoDB 파일 조작에만 적용하려면 innodb_flush_method = O_DIRECT 를 설정합니다. 이 설정은 InnoDB 는 데이터 파일에 대한 I / O (로그 파일에 대한 I / O가 아닌)에 fcntl() 대신 directio() 를 호출합니다.
Solaris 2.6 이상의 모든 버전 및 모든 플랫폼 (sparc / x86 / x64 / amd64)에서 큰 innodb_buffer_pool_size 값을 사용하여 InnoDB 스토리지 엔진을 사용하는 경우, 앞서의 forcedirectio 마운트 옵션을 사용하여 raw 장치 또는 개별 다이렉트 I / O UFS 파일 시스템에서 InnoDB 데이터 파일과 로그 파일의 벤치 마크를 실행합니다. (로그 파일의 직접 I / O가 필요한 경우 innodb_flush_method 를 설정하는 대신 마운트 옵션을 사용해야합니다.) Veritas 파일 시스템 VxFS 사용자는 convosync=direct 마운트 옵션을 사용하십시오.

다이렉트 I / O 파일 시스템에 MyISAM 테이블의 파일 등 다른 MySQL 데이터 파일을 배치하지 마십시오. 실행 파일 및 라이브러리는 다이렉트 I / O 파일 시스템에 배치하지 마십시오.
RAID 구성 또는 다른 디스크에 대한 심볼릭 링크를 설정하기 위해 추가 저장 장치를 사용할 수 있도록하려면 추가 저수준 I / O 팁 내용은 섹션 8.11.3 "디스크 I / O 최적화 화 " 를 참조하십시오.
InnoDB 체크 포인트 작업 처리 속도를 주기적으로 하락하는 경우 innodb_io_capacity 구성 옵션의 값을 증가하는 것을 고려합니다. 값을 크게하면 플래시 가 자주 간다 처리량을 저하시킬 수있는 작업의 백 로그를 피할 수 있습니다.
InnoDB 플래시 작업은 시스템이 늦지 않으면 innodb_io_capacity 구성 옵션의 값을 작게하는 것을 고려합니다. 일반적으로이 옵션 값은 최소화되지만 이전 글 머리 기호에서 나타낸 바와 같이 처리량에주기적인 저하가 발생할 정도로 작게 마십시오. 옵션 값을 줄일 수있는 일반적인 시나리오에서는 SHOW ENGINE INNODB STATUS 의 출력에 다음과 같은 조합이 나타날 수 있습니다.
- 기록 목록의 길이가 짧아 수천 미만입니다.
- 삽입 버퍼 병합 수가 삽입 된 행 수에 가깝습니다.
- 버퍼 풀의 변경된 페이지가 지속적으로 버퍼 풀의 innodb_max_dirty_pages_pct 을 훨씬 밑돌고 있습니다. (서버가 대량 삽입을 실행하지 않을 때 측정합니다. 변경된 페이지의 일괄 삽입 할 때 비율이 크게 높아지는 것은 정상입니다.)
- Log sequence number - Last checkpoint 가 InnoDB 로그 파일 의 전체 크기의 7/8보다 작거나 이상적으로는 6/8 미만입니다.
I / O에 의존 한 작업 튜닝시 고려해야 기타 InnoDB 구성 옵션에는 다음이 포함됩니다 : innodb_adaptive_flushing , innodb_change_buffer_max_size , innodb_change_buffering , innodb_flush_neighbors , innodb_log_buffer_size , innodb_log_file_size , innodb_lru_scan_depth , innodb_max_dirty_pages_pct , innodb_max_purge_lag , innodb_open_files , innodb_page_size , innodb_random_read_ahead , innodb_read_ahead_threshold , innodb_read_io_threads , innodb_rollback_segments , innodb_write_io_threads 및 sync_binlog .