innodb_flush_method = O_DIRECT 대 O_DSYNC 성능이 LVM 디스크 파티션이있는 ext3에 미치는 영향


12

프로덕션 환경 중 하나에는 RedHat 클러스터에서 두 개의 인스턴스가 실행되고 하나는 클러스터와 연결된 하나의 프로덕션 인스턴스가 있습니다.

인스턴스 1이 차지하는 24G InnoDB 버퍼 풀과 인스턴스 2가 차지하는 12G가있는 125G 기본 메모리가 있으며 이는 RedHat 클러스터와 관련이 없습니다. 데이터 및 트랜잭션 로그는 모두 ext3 파일 시스템이있는 LVM 디스크 파티션에 있습니다.

성능 향상 및 더 나은 I / O 처리량을 위해로 변경 innodb_flush_method하기 로 결정했습니다 O_DIRECT.

MySQL 문서를 참조하십시오.

InnoDB 데이터 및 로그 파일이 SAN에있는 경우 간단한 명령문의 성능 을 3 배 저하시킬 수 있는 설정 innodb_flush_methodO_DIRECT있습니다 SELECT.

고성능 MySQL Ver 2 및 3을 참조하면 InnoDB 개발자는를 사용하여 버그를 발견했다고 언급했습니다 innodb_flush_method=O_DSYNC. O_SYNCO_DSYNC비슷 fsync()하고 fdatasync(): O_SYNC반면, 동기화 데이터와 메타 데이터를 O_DSYNC동기화 데이터뿐만.

그 모든 것이 조언없이 많은 설명처럼 보이면 다음 조언이 있습니다.

Unix와 유사한 운영 체제를 사용하고 RAID 컨트롤러에 배터리 지원 쓰기 캐시가있는 경우을 사용하는 것이 좋습니다 O_DIRECT. 그렇지 않은 경우 O_DIRECT응용 프로그램에 따라 기본값 또는 아마도 최선의 선택 일 것입니다.

인터넷 검색, 나는이있어 벤치 마크 보고서 :에 O_DSYNCO_DIRECT

벤치 마크 보고서 :
====================
1B 행 복합 트랜잭션 테스트, 64 스레드

 * SAN O_DIRECT : 읽기 / 쓰기 요청 : 31560140 (초당 8766.61)
 * SAN O_DSYNC : 읽기 / 쓰기 요청 : 5179457 (초당 1438.52)
 * SAN fdatasync : 읽기 / 쓰기 요청 : 9445774 (2623.66 / 초)
 * 로컬 디스크 O_DIRECT : 읽기 / 쓰기 요청 : 3258595 (초당 905.06)
 * 로컬 디스크 O_DSYNC : 읽기 / 쓰기 요청 : 3494632 (970.65 / 초)
 * 로컬 디스크 fdatasync : 읽기 / 쓰기 요청 : 4223757 (초당 1173.04)

그러나 O_DIRECT이중 캐싱을 비활성화하여 I / O 처리량을 향상시킬 수있는 OS 수준 캐시를 비활성화합니다.

O_DIRECT오히려 함께가는 것이 좋 O_DSYNC습니까? 이 두 가지 옵션은 약간 혼동됩니다. 특히 프로덕션 환경에서 데이터, 읽기 / 쓰기에 영향을 미치지 않으면 서 I / O 처리량을 높이고 성능을 향상시킬 수있는 옵션은 무엇입니까? 개인적인 경험에 근거한 더 나은 제안이 있습니까?

게시물 에서 Rolando Update를 볼 수 있습니다 .

여전히이 두 매개 변수에 약간의 혼란이 있습니다. 를 사용하여 대부분의 프로덕션 구성 템플릿을 O_DIRECT볼 수있는 곳에서는 권장하는 곳을 보지 못했습니다 O_DSYNC.

체계

  • MySQL 5.1.51-enterprise-gpl-pro-log
  • Red Hat Enterprise Linux Server 릴리즈 5.5
  • 배터리 쓰기 캐시가있는 Raid Controller가있는 DELL DRAC 512MB
  • 배터리 백업 장치 (BBU)가 장착 된 Dell PERC 컨트롤러 H700.

추가 정보

mysql>은 'innodb_thread_concurrency'와 같은 변수를 보여줍니다; 

+ --------------------------- + ------- +
| Variable_name | 가치 |
+ --------------------------- + ------- + 
| innodb_thread_concurrency | 96 |
+ --------------------------- + ------- + 
1 행 세트 (0.00 초) 

mysql>은 'innodb_read_io_threads'와 같은 변수를 보여줍니다; 
빈 세트 (0.00 초) 

mysql>은 'innodb_write_io_threads'와 같은 변수를 보여줍니다; 
빈 세트 (0.00 초)

우리는 기본 플러그인을 사용하고 있으므로 InnoDB 상태에서 정보를 게시했습니다.

mysql> PLUGIN_NAME이 '% innodb %'이고 PLUGIN_TYPE이 'STORAGE ENGINE'\ G 인 플러그인에서 SELECT * FROM
*************************** 1. 행 *********************** *******
           PLUGIN_NAME : InnoDB
        PLUGIN_VERSION : 1.0
         PLUGIN_STATUS : 활성
           PLUGIN_TYPE : 스토리지 엔진
   PLUGIN_TYPE_VERSION : 50151.0
        PLUGIN_LIBRARY : NULL
PLUGIN_LIBRARY_VERSION : NULL
         PLUGIN_AUTHOR : 이노베이스 OY
    PLUGIN_DESCRIPTION : 트랜잭션, 행 수준 잠금 및 외래 키 지원
        PLUGIN_LICENSE : GPL
1 행 세트 (0.00 초)

답변:


7

2009 년 1 월 21 일 Peter Zaitsev는 mysqlperformanceblog.com에 다음과 같이 언급했습니다.

행동의 요구로 – 나는 누군가가 EXT3가 리눅스에서 가장 일반적인 파일 시스템 인 것처럼 이와 관련하여 고칠 수 있는지 확인하고 싶다. MySQL 쪽에서 무언가를 할 수 있는지 조사하는 것도 가치가있다. fsync를 사용 O_DSYNC하는 sync_binlog=1대신 도움이 된다면 플래그로 binlog를 열 수 있을까? 또는 binlog 사전 할당이 좋은 솔루션 일 수 있습니다.

현재로서는 아무도이 문제를 다루지 않았습니다. O_DSYNC기본적으로 매력적인 잠재 고객은 아니지만 실제로 확인되지 않은 더 빠른 쓰기를 수용합니다. 그 주위에 너무 많은 과대 광고가있는 이유 O_DIRECT.

InnoDB 플러그인이 설치되어 있지 않다고 말할 수 있습니다. InnoDB 플러그인에는 몇 가지 변수가 있어야합니다.

다음 두 가지 방법 중 하나로 InnoDB를 업그레이드해야합니다.

일단 그렇게하면 InnoDB를 향상시킬 수 있습니다

  • 더 많은 CPU 및 코어에 액세스
  • 읽기 및 쓰기 I / O 스레드 증가
  • I / O 용량 확장 (특히 다른 저장 매체에 필요)

다음은이 설정을 변경할 수있는 지난 게시물입니다.


1

나는 항상 O_DIRECT이중 버퍼링을 막기 때문에 성능에 더 좋은 인상을 받았습니다 . 또한 배터리 지원 쓰기 캐시가있는 하드웨어 RAID가있는 경우. 물론 읽기 또는 쓰기 중하 든 워크로드에 따라 다릅니다.

또한, 문제는 전문가 :에 추가 호출을 fsync()위한 O_DIRECT원인 전반적인 성능이 눈에 띄게 저하, 또는 무시할? 나는 아직 벤치 마크가 이것을 보지 못했다.

또한 Percona는 innodb_flush_method=ALL_O_DIRECTInnoDB 데이터 파일뿐만 아니라 InnoDB 트랜잭션 로그에서도 직접 I / O를 제공 하는 설정 기능을 활성화했습니다 .


2
2012 년에 버퍼 풀은 대용량 RAM에 대해 잘 확장되지 않았으므로 OS 캐시가 innodb 버퍼 풀보다 훨씬 큰 경우 이중 버퍼링이 적합 할 수 있습니다. 5.6 이상에서-귀하의 답변이 완전히 유효하다고 말합니다.
noonex
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.