MySQL에서 둘 이상의 코어를 사용할 수 있습니까?

단일 코어 이상을 사용하지 않는 일부 전용 MySQL 서버가 제공되었습니다. MySQL 용 DBA보다 개발자이므로 도움이 필요합니다.

설정

서버는 OLAP / DataWarehouse (DW) 유형로드로 상당히 무겁습니다.

• 기본 : 96GB RAM, 8 코어 + 단일 RAID 10 어레이
• 테스트 : 4 코어 32GB RAM
• 가장 큰 DB는 540GB이고, 전체는 약 1.1TB이며 대부분 InnoDB 테이블
• 솔라리스 10 Intel-64
• MySQL 5.5.x

참고 : 가장 큰 DB는 OLTP DR 서버에서 복제 된 데이터베이스이며 DW는이 데이터베이스에서로드됩니다. 전체 DW는 아닙니다. 단지 6 개월에서 6 주까지 지속되므로 OLTP DB보다 작습니다.

테스트 서버에서의 관찰

• 3 개의 개별 연결
• 각각은 동시에 (그리고 다른) ALTER TABLE...DROP KEY...ADD INDEX
• 3 개의 테이블은 2.5, 3.8, 450 만 행
• CPU 사용량이 최대 25 % (한 코어가 최대로 초과) 이상으로 증가하지 않음
• 3 개의 ALTER는 12-25 분이 소요됩니다 (가장 작은 것에는 4.5가 걸립니다)

질문

1. 둘 이상의 코어를 사용하려면 어떤 설정 또는 패치가 필요합니까?
   즉, MySQL이 사용 가능한 모든 코어를 사용하지 않는 이유는 무엇입니까? (다른 RDBMS와 마찬가지로)
2. 복제의 결과입니까?

기타 노트

• RDBMS "스레드"와 OS "스레드"의 차이점을 이해합니다
• 나는 어떤 형태의 병렬 처리를 요구하지 않습니다.
• InnoDB 및 스레드에 대한 일부 시스템 변수는 차선책입니다
  (빠른 승리를 기대 함)
• 단기적으로 디스크 레이아웃을 변경할 수 없습니다
• 필요한 경우 OS를 조정할 수 있습니다
• 가장 작은 테이블의 단일 ALTER TABLE은 4.5 분이 걸립니다 (충격 IMO).

편집 1

• innodb_thread_concurrency는 둘 다에서 8로 설정됩니다. 예, 잘못되었지만 MySQL이 다중 코어를 사용하지는 않습니다.
• innodb_buffer_pool_size는 기본에서 80GB이고 테스트에서 10GB입니다 (다른 인스턴스가 종료 됨). 지금은 괜찮습니다.
• innodb_file_per_table = ON

편집 2

• innodb_flush_log_at_trx_commit = 2
• innodb_use_sys_malloc = ON
• innodb_flush_method는 O_DIRECT 여야하지만 SHOW VARIABLES는이를 표시하지 않습니다.
• innodb_doublewrite = OFF
• 파일 시스템 = ZFS (그리고 내 sysadmin이 이것을 찾았습니다 : http://blogs.oracle.com/realneel/entry/mysql_innodb_zfs_best_practices )

테스트

• innodb_flush_method는 O_DIRECT로 표시되지 않습니다.
• RolandoMySQLDBA의 설정을 따릅니다.

중요한 것을 놓친 경우 알려주세요

건배

최신 정보

RolandoMySQLDBA의 응답에서 innodb_flush_method + 3 x 스레드 설정 변경
결과 :> 테스트에 사용 된 1 코어 = 긍정적 인 결과

실제로 2011 년 5 월 Percona Live NYC 컨퍼런스에서 MySQL 전문가와 innodb_thread_concurrency에 대해 논의했습니다 .

나는 놀라운 것을 배웠다 : 문서에도 불구하고 innodb_thread_concurrency0 (무한 동시성) 으로 두는 것이 가장 좋습니다 . 이런 식으로 InnoDB는 innodb_concurrency_tickets주어진 MySQL 인스턴스 설정에 대해 가장 많은 수의 열림을 결정합니다 .

사용자가 설정되면 innodb_thread_concurrency0으로, 당신은 설정할 수 있습니다 innodb_read_io_threads및 innodb_write_io_threads더 많은 코어 참여한다 (64)이 최대 값 (모두의 MySQL 5.1.38 이후)를.

MySQL은 자동으로 여러 코어를 사용하므로 25 %의로드가 일치 ¹ 이거나 Solaris에서 잠재적으로 잘못 구성 될 수 있습니다. 솔라리스를 튜닝하는 방법을 모르는 척하지만, 여기에는 솔라리스 관련 튜닝 정보를 다루는 기사가 있습니다.

InnoDB 튜닝 페이지는 MySQL 5.5에서 정밀 검사를 받았으므로 좋은 정보도 있습니다. 로부터 이노 디스크 IO 팁 :

Unix 최상위 도구 또는 Windows 작업 관리자에 작업 부하의 CPU 사용률이 70 % 미만인 것으로 표시되면 작업 부하가 디스크 바인딩 된 것일 수 있습니다. 트랜잭션 커밋이 너무 많거나 버퍼 풀이 너무 작을 수 있습니다. 버퍼 풀을 더 크게 만들면 도움이 될 수 있지만 실제 메모리의 80 % 이상으로 설정하지 마십시오.

확인해야 할 다른 것들 :

• innodb_flush_method 를 O_DIRECT로 전환하는 것은 테스트 할 가치가 있습니다. 이것이 도움이된다면, forcedirectio옵션으로 파일 시스템을 마운트해야 할 수도 있습니다

• innodb_flush_log_at_trx_commit 을 1에서 0으로 변경하십시오 (mysql 충돌에서 마지막 1 초를 잃어 버릴 염려가 없다면) 또는 2 (OS 충돌에서 마지막 1 초를 잃어 버릴 염려가 없다면).

• innodb_use_sys_malloc 값을 확인하십시오 . 이 기사에는 변수에 대한 자세한 정보 가 있습니다.

  그 당시에는 멀티 코어 CPU에 맞게 조정 된 메모리 할당 자 라이브러리가 없었습니다. 따라서 InnoDB는 mem 서브 시스템에서 자체 메모리 할당자를 구현했습니다. 이 할당자는 단일 뮤텍스에 의해 보호되며 병목 현상이 발생할 수 있습니다.

  그러나 섹션 끝에는 변수를 켜는 것이 무엇을 의미하는지에 대한 몇 가지주의 사항이 있습니다 (5.5에서는 기본적으로 켜져 있음).

  InnoDB 메모리 할당자가 비활성화되면 InnoDB는 innodb_additional_mem_pool_size 매개 변수의 값을 무시합니다.

• 복제로 인해 일부 문제가 발생했을 수 있습니다. 나는 병렬 처리에 관심 이 없지만이 작업 로그에 대한 설명에서 관심이 있음을 알고 있습니다 .

  현재 복제는 다중 코어 시스템에서 제대로 확장되지 않습니다. 단일 슬레이브 스레드는 복제 이벤트를 하나씩 실행하며 별도의 마스터 서버의 CPU가 제공하는 동시 여러 클라이언트 연결에서 생성 된로드에 대처할 수 없습니다.

궁극적으로 InnoDB는 발생하는 디스크 기반 작업으로 인해 데이터웨어 하우징에 가장 적합한 엔진이 아닐 수 있습니다. 데이터웨어 하우스 테이블을 압축 MyISAM으로 변경하는 것을 고려할 수 있습니다 .

¹ _{우연의 일치로,로드가 25 % 이상 증가하는 것을 막는 병목 현상이 발생하지만 반드시 단일 코어 문제 일 필요는 없습니다.}

단일 연결은 단일 코어 만 사용합니다. (OK, InnoDB는 일부 I / O 처리에 다른 스레드를 사용하므로 코어를 사용하지만 그다지 중요하지는 않습니다.)

3 개의 ALTER가 있으므로 3 코어 이상의 가치를 사용하지 않았습니다.

아아, PARTITION조차도 여러 코어를 사용하지 않습니다.

최근까지는 4-8 코어 후에 여러 연결이 최대로 확장되었습니다. Percona의 Xtradb (MariaDB에 포함)는 여러 코어를 더 잘 사용하지만 스레드 당 하나만 사용합니다. 그들은 약 32 코어에서 최대입니다.

IMHO 및 설명 된 사용 사례에서는 둘 이상의 코어를 사용하지 않습니다. 워크로드가 CPU 바운드가 아니라 IO 바운드이기 때문입니다. 3 개의 연결이 새로운 인덱스를 생성함에 따라 디스크에서 전체 테이블을 읽어야합니다. 인덱스를 계산하지 않고 시간이 걸리는 것입니다.

병목 현상은 파일 시스템의 IO 성능 일 수 있습니다.

@RolandoMySQLDBA가 제안한 설정 외에도 mysql 데이터 디렉토리를 보유하는 파티션 noatime에 /etc/fstab대한 마운트 설정 도 설정했습니다 ( /data01/mysql내 경우에는 /dev/sdb1마운트 된 /data01).

기본적으로 linux는 모든 디스크 읽기 또는 쓰기에 대한 액세스 시간을 기록하여 특히 데이터베이스와 같은 높은 IO 응용 프로그램의 경우 IO 성능에 부정적인 영향을 미칩니다. 이것은 파일에서 데이터를 읽더라도 디스크에 쓰기를 트리거한다는 것을 의미합니다. WAT!

이를 비활성화하려면 다음과 같이 원하는 마운트 지점 noatime에 마운트 옵션을 추가하십시오 /etc/fstab(필자의 경우).

/dev/sdb1  /data01  ext4  defaults,noatime  0  2

그런 다음 파티션을 다시 마운트하십시오.

mount -o,remount /data01

그러면 해당 파티션을 사용하는 응용 프로그램의 읽기 / 쓰기 성능이 향상됩니다. 그러나 ... 모든 데이터를 메모리에 보관하는 것보다 좋은 것은 없습니다.