사용자는 mysqldump가 진행 중일 때 시스템이 느리게 작동한다고 불평합니다

MYSQL 데이터베이스 (ibdata1)의 크기는 73GB이며 INNODB 테이블 용 Windows 2008 O / S에서 전용 데이터베이스 서버로 실행되도록 구성되어 있습니다. mysqldump --skip-opt --quick --single-transaction --create-options --extended-insert --disable-keys --add-drop-table --complete-insert-를 사용하여 백업을 실행하고 있습니다. set-charset-compress --log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

백업 파일 Proddb0635.sql은 데이터베이스 서버와 별도의 서버에 저장됩니다. RAM은 12GB입니다. INNODB 버퍼 풀 크기는 6GB입니다. 추가 mem.pool은 32MB입니다. 쿼리 캐시 크기는 2GB입니다. Net 버퍼 길이는 최대 16M입니다. 패킷 크기 1GB.

mysql 버전은 5.0.67입니다.

백업이 실행되고 있지 않으면 사용자는 성능에 만족합니다.

백업이 실행될 때 INNODB 버퍼 풀 적중률은 100 %에 가깝습니다. 보류중인 읽기 또는 보류중인 쓰기가 없습니다. innodb wait free는 0입니다. CPU 사용량이 높지 않음 최소 9 % ~ 최대 15 % 쿼리 캐시 적중률은 mysqlbackup을 실행하거나 실행하지 않고 약 40 %입니다. 현재 Windows 작업 관리자는 10GB의 RAM이 사용되고 있음을 표시하고 있습니다. 2GB의 RAM 만 사용하여 쿼리 캐시를 늘려야합니까? mysqlld-nt는 9.2GB의 RAM을 사용하고 mysqldump는 5MB의 RAM을 사용합니다. Alos는 덤프 파일의 크기가 --compress 옵션의 존재 유무와 동일하다는 점에 주목했습니다.

iNNODB 버퍼 풀 크기를 줄여야합니까?

감사

Windows에는 대용량 파일을 다른 서버로 푸시하면 모든 메모리가 사용자 프로세스 대신 시스템 캐시에 할당되는 알려진 문제가 있습니다. 작업 관리자의 실제 메모리 (MB) 섹션에서 시스템 캐시에 할당 된 메모리 양을 확인할 수 있습니다.

이것은 로컬 디스크에 백업 한 다음 원격 시스템이 해당 파일을 가져 오도록하여 해결할 수 있습니다.

다음은 상황에 따라 mysqldump 성능을 개선하는 데 대한 몇 가지 생각입니다. 여기 당신의 명령이 있습니다 :

mysqldump --skip-opt --quick --single-transaction --create-options --extended-insert --disable-keys --add-drop-table --complete-insert --set-charset --compress- -log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

가장 먼저 눈에 띄는 것은 출력을 파일 시스템으로 리디렉션한다는 것입니다. 'devNas'라고 표시되어 있으므로 이것이 Network Attached Storage 라고 가정하겠습니다 . 백업용 NAS의 팬이지만 프로덕션 트래픽과 별도의 물리적 NIC 에 연결되어 있어야합니다 . 대역폭을 포화시키지 않을 수 있지만 여전히 경쟁합니다. --quick 플래그로 인해 메모리에 유지하는 대신 모든 행을 플러시하기 때문에 더 많은 문제가 발생합니다.

다음으로 보시는 것은 --compress를 호출 한 것입니다. -h 스위치를 사용하지 않았기 때문에 로컬에서 mysql을 실행하는 것 같습니다. 이 상황에서 불필요한 로컬 CPU를 사용할 수 있습니다. 압축이 필요합니까? 파일 내용이 아닌 mysqldump 클라이언트와 mysql 서버 사이의 데이터 만 압축합니다.

다음으로 --single-transaction 플래그를 사용하고 있습니다. 이것은 mysqldump의 일부로 모든 선택에서 테스트 할 때 추가 CPU를 발생시킵니다.

이것은 성능과 관련이 없지만 MyISAM ( manual ) 에서만 작동하는 --disable-keys를 사용하고 있습니다.

오프라인 호스트에서 원격으로 mysqldump를 실행하고 완료 후 덤프 파일을 NAS로 이동하여 가능한 많은 대역 외에서이 작업을 수행 할 수 있습니다.

관찰 # 1

InnoDB에 대해 mysqldump를 수행 할 때 명심해야 할 것이 있습니다.

InnoDB 버퍼 풀에 존재하는 더티 페이지는 먼저 디스크로 플러시되어야합니다. mysqldump는 여전히 더티 페이지가있는 InnoDB 테이블의 플러시를 트리거합니다.

innodb_max_dirty_pages_pct 라는 서버 옵션이 있습니다 . 기본값은 75 이전의 MySQL 버전 5.5에서 MySQL 5.5 및 90입니다. 프로덕션 환경에서는이 숫자를 기본값으로 두는 것이 좋습니다.

InnoDB 버퍼 풀에 더티 페이지가 많이 있는지 확인하려면 다음을 실행하십시오.

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty';

BTW 페이지는 다음과 같이 16K입니다.

SHOW GLOBAL STATUS LIKE 'Innodb_page_size';

InnoDB와 mysqldump는 두 가지 상황에서이 수를 줄일 수 있습니다.

CIRCUMSTANCE 1 : 영구적으로 0으로 설정

이것을 my.ini에 추가하십시오.

[mysqld]
innodb_max_dirty_pages_pct=0

이것은 InnoDB 버퍼 풀을 간결하게 유지합니다. mysqldump가 작동하기 전에 가능한 약간의 더티 페이지 (아마도 0)를 플러시해야하기 때문에 덤프되는 InnoDB 테이블을 플러시하는 단계가 빠르다.

유일한 단점은 트래픽이 많은 DB에서 mysqldump를 사용하는 경우 더티 페이지를 더 자주 플러시하기 때문에 쓰기 I / O가 약간 증가 할 수 있다는 것입니다. 다음을 실행하여 restartnig mysql이 없는지 확인할 수 있습니다.

SET GLOBAL innodb_max_dirty_pages_pct = 0;

쓰기 성능이 만족 스러우면 12-24 시간 동안 설정을 유지하십시오. 그렇지 않은 경우 다음과 같이 다시 설정하십시오.

SET GLOBAL innodb_max_dirty_pages_pct = 90;

CIRCUMSTANCE 2 : mysqldump 약 1 시간 전에 0으로 설정

SET GLOBAL innodb_max_dirty_pages_pct = 0;

mysqldump를 실행

SET GLOBAL innodb_max_dirty_pages_pct = 90;

관찰 # 2

당신은이 --complete-삽입 mysqldump를 옵션으로합니다. VALUES 절 앞의 모든 INSERT 통계에 열 이름이 포함됩니다. --extended-insert를 사용하더라도 삽입되는 모든 행 배치에서 열 이름이 mysqldump로 전송됩니다. --complete-insert를 제거하여 mysqldump에 전송되는 바이트의 양을 줄일 수 있습니다.

추천

슬레이브로 설정할 수있는 다른 Windows Server가있는 경우 프로덕션 머신이 아닌 해당 슬레이브에서 mysqldump를 수행하십시오.