높은 IO 대기-근본 원인을 확인하는 방법? 1474 0.0 0.0

두 개의 전용 서버에 MySQL 인스턴스가 있습니다. 하나는 프로덕션 용이고 다른 하나는 테스트 플랫폼 용입니다.

두 서버는 거의 동일하지만 유일한 차이점은 RAID 컨트롤러와 가상 볼륨입니다 (HD는 동일 함). 프로덕션 환경에는 전용 HW RAID 컨트롤러와 RAID 10 볼륨이 있습니다. 다른 한편으로, RAID 컨트롤러는 소프트웨어 (Lenovo ThinkServer RAID 110i)이고 볼륨은 RAID 5입니다.

우리는 MySQL 커밋 동안 높은 대기 시간이 있음을 알았습니다.

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

dm-10-8 및 dm-14-8은 데이터베이스 파티션과 관련이 있습니다. 

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

레이드 컨트롤러를 의심합니다. 어떻게 확신 할 수 있습니까?

답변

내 대답에는 두 부분이 있습니다. 블록 장치 드라이버 조사; 사용 사례를 살펴볼 가치가있는 최적화 그러나 데이터 손실로 이어질 수 있다고보고 된 마지막 부분을 제거했습니다. 의견을 참조하십시오.

하드웨어 조사

동일한 응용 프로그램이지만 2 개의 다른 하드웨어 세트에서 성능이 매우 다르며 그 이유를 이해하고 싶습니다. 따라서 먼저 “이유”에 대한 답변을 찾는 데 도움이되는 방법을 제안합니다.

성능을 위해, 나는 종종 그의 블로그에서 Brendan Gregg가 제공 하는 Linux 성능 맵을 참조합니다 . 낮은 수준 (하드웨어에 가장 가까운)의 경우와 같은 도구 blktrace가 완벽하다는 것을 알 수 있습니다.

이 도구를 실제로 알지 못하면서 Marc Brooker의 blktrace 에 관한 흥미로운 기사를 검색했습니다 . 기본적으로 다음을 제안합니다 blktrace.;를 사용하여 I / O 추적 수행 사용 BTT의 도구는이 추적에서 정보를 추출합니다. 이것은 다음과 같습니다 (30 초 추적).

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

출력은 상당히 길 수 있지만 D2C 항목을 찾으십시오. 장치 드라이버에 전달 된 I / O가이 드라이버에 의해 완료된 것으로보고되는 데 걸리는 시간에 대한 정보를 제공합니다.

출력 예 (사용 dnf upgrade중인 랩탑의 VirtualBox VM에서 실행) :

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

최악의 경우 최대 3,94 초로 I / O 당 평균 45ms의 실망을 보여줍니다!

blktrace를 사용하여이 조사를 수행하는 다른 방법은 Marc Brooker의 기사를 참조하십시오.

답변

jbd2 프로세스는 ext4 저널링을위한 것입니다. mysql 커밋 중에 파일 시스템이 저널에 기록되어야하는 것이 논리적이므로 걱정할 필요가 없습니다. jbd로 인한로드 양은 dm-10-8 및 dm-14-8 파티션의 마운트 매개 변수에 영향을받습니다. 데이터베이스 파티션에서 매우 보존적인 저널링을 수행하여 문제가 발생하거나 서버가 실수로 재부팅되는 경우 데이터베이스가 손상되지 않도록하는 것이 좋습니다. 테스트 환경에서 비교하기 위해 다른 저널링 마운트 옵션을 선택할 수 있습니다.

답변