새로운 경로 탐색 - IO 대기 진단 도구

소개	최근 로그 실시간 동기화를 하고 있는데, 온라인에 접속하기 전에 단일 온라인 로그 스트레스 테스트를 했는데, 메시지 큐, 클라이언트, 로컬 머신에는 문제가 없었습니다. 두 번째 로그가 업로드된 후에 문제가 발생한 것으로 예상됩니다.

1. 질문:

클러스터 상단의 특정 머신에서 엄청난 로드가 발생했습니다. 클러스터의 머신은 동일한 하드웨어 구성과 동일한 배포된 소프트웨어를 가지고 있지만 이 머신에는 처음에는 하드웨어 문제가 있는 것으로 추측됩니다.

동시에 비정상적인 부하의 원인을 찾아내고 소프트웨어 및 하드웨어 수준에서 해결책을 찾아야 합니다.

2. 문제 해결:

위에서 보면 로드 평균이 높고, %wa가 높고, %us가 낮다는 것을 알 수 있습니다.

위 그림에서 IO에 병목 현상이 발생했음을 대략적으로 추론할 수 있습니다. 다음으로 특정 확인 및 문제 해결을 위해 관련 IO 진단 도구를 사용할 수 있습니다.

일반적으로 사용되는 조합 방법은 다음과 같습니다.
•vmstat, sar, iostat를 사용하여 CPU 병목 현상인지 감지
• 메모리 병목 현상이 있는지 감지하려면 free 및 vmstat를 사용하세요
•iostat 및 dmesg를 사용하여 디스크 I/O 병목 현상인지 감지
•netstat를 사용하여 네트워크 대역폭 병목 현상 감지

2.1 vmstat

vmstat 명령의 의미는 가상 메모리 상태("Virtual Memory Statics")를 표시하는 것이지만 프로세스, 메모리, I/O 등 시스템의 전반적인 작동 상태를 보고할 수도 있습니다.

관련 분야는 다음과 같습니다:

프로세스
•r: 실행 대기열에 있는 프로세스 수입니다. 이 값은 CPU를 늘려야 하는지 여부를 결정하는 데에도 사용할 수 있습니다. (1보다 큰 장기)
•b: IO를 기다리는 프로세스 수, 즉 Non-Interruptible Sleep 상태의 프로세스 수로 실행 중이며 CPU 자원을 기다리는 작업 수를 나타냅니다. 이 값이 CPU 수를 초과하면 CPU 병목 현상이 발생합니다

메모리
•swpd: 가상 메모리 크기를 사용합니다. swpd의 값이 0이 아니지만 SI 및 SO의 값이 오랫동안 0인 경우 이러한 상황은 시스템 성능에 영향을 미치지 않습니다.
•free: 여유 물리적 메모리 크기입니다.
•buff: 버퍼로 사용되는 메모리의 크기.
• 캐시: 캐시로 사용되는 메모리 크기입니다. 캐시 값이 크다면 캐시에 많은 파일이 있다는 의미입니다. 자주 액세스하는 파일을 캐시할 수 있다면 디스크의 읽기 IO bi가 매우 작습니다.

스왑(교환지역)
•si: 디스크에서 메모리로 전송되는 초당 스왑 영역에서 메모리로 쓰는 크기입니다.
•so: 메모리에서 디스크로 전송되는 초당 스왑 영역에 기록되는 메모리 크기입니다.

참고: 메모리가 충분할 경우 이 두 값은 모두 0입니다. 이 두 값이 오랫동안 0보다 큰 경우 시스템 성능에 영향을 미치고 디스크 IO 및 CPU 리소스가 소비됩니다. 어떤 친구들은 여유 메모리(free)가 아주 작거나 0에 가까운 것을 보면 메모리가 부족하다고 생각합니다. 이것만 볼 수는 없고, si 등도 합치면 여유 메모리가 아주 적습니다. si도 거의 없으므로(대부분 0임) 걱정하지 마십시오. 현재로서는 시스템 성능에 영향을 미치지 않습니다.

IO(입력 및 출력)

(Linux 버전 블록 크기는 현재 1kb입니다)
•bi: 초당 읽은 블록 수
•bo: 초당 작성된 블록 수

참고: 임의의 디스크를 읽고 쓸 때 이 두 값이 클수록(예: 1024k 초과) 값이 클수록 CPU가 IO를 기다리고 있음을 알 수 있습니다.

시스템
•in: 클럭 인터럽트를 포함한 초당 인터럽트 수입니다.
•cs: 초당 컨텍스트 전환 횟수입니다.

참고: 위의 두 값이 클수록 커널이 소비하는 CPU 시간도 커집니다.

CPU

(백분율로 표시)
•us: 사용자 프로세스 실행 시간의 백분율(사용자 시간)입니다. 우리의 가치가 상대적으로 높다는 것은 사용자 프로세스가 CPU 시간을 많이 소모한다는 것을 의미하지만, 사용량이 장기간 50%를 초과한다면 프로그램 알고리즘을 최적화하거나 가속하는 것을 고려해야 합니다.
•sy: 커널 시스템 프로세스 실행 시간 비율(시스템 시간)입니다. sy 값이 높으면 시스템 커널이 많은 CPU 리소스를 소비한다는 의미이므로 성능이 양호하지 않으므로 이유를 확인해야 합니다.
•wa: IO 대기 시간 비율. wa 값이 높다는 것은 IO 대기가 심각하다는 것을 의미하는데, 이는 디스크에 대한 랜덤 액세스가 많거나 디스크에 병목 현상(블록 작업)이 있을 수 있기 때문일 수 있습니다.
•id: 유휴 시간 비율

vmstat에서 볼 수 있듯이 대부분의 CPU 시간은 IO를 기다리는 데 낭비됩니다. 이는 다수의 임의 디스크 액세스 또는 디스크 대역폭으로 인해 발생할 수 있습니다. 이는 bi와 bo 모두 1024k를 초과하며 이는 IO 병목 현상을 나타냅니다.

2.2 iostat

좀 더 전문적인 디스크 IO 진단 도구를 사용하여 관련 통계를 살펴보겠습니다.

관련 분야는 다음과 같습니다.
•rrqm/s: 초당 병합 읽기 작업 수입니다. 그것은 델타(rmerge)/s
입니다. •wrqm/s: 초당 병합 쓰기 작업 수입니다. 그것은 델타(wmerge)/s
입니다. •r/s: 초당 완료된 I/O 장치 읽기 수입니다. 그건 delta(rio)/s
•w/s: 초당 완료된 I/O 장치 쓰기 횟수입니다. 그건 델타(wio)/s
•rsec/s: 초당 읽은 섹터 수입니다. 그것은 델타(rsect)/s
입니다. •wsec/s: 초당 쓴 섹터 수입니다. 그것은 델타(wsect)/s
입니다. •rkB/s: 초당 K바이트를 읽습니다. 각 섹터 크기가 512바이트이므로 RSect/s의 절반입니다. (계산 필요)
•wkB/s: 초당 쓴 K바이트 수입니다. wsect/s의 절반입니다. (계산 필요)
•avgrq-sz: 장치 I/O 작업당 평균 데이터 크기(섹터)입니다. 델타(rsect+wsect)/델타(rio+wio)
•avgqu-sz: 평균 I/O 대기열 길이입니다. delta(aveq)/s/1000 입니다(aveq의 단위가 밀리초이기 때문입니다).
•await: 각 장치 I/O 작업에 대한 평균 대기 시간(밀리초)입니다. 그게 바로 델타(ruse+wuse)/delta(rio+wio)입니다
•svctm: 장치 I/O 작업당 평균 서비스 시간(밀리초)입니다. 그게 바로 델타(사용)/델타(rio+wio)
입니다. •%util: I/O 작업에 사용되는 시간(초) 또는 I/O 대기열이 비어 있지 않은 시간(초)입니다. delta(use)/s/1000 입니다 (사용 단위가 밀리초이기 때문입니다)

두 하드 디스크의 sdb 사용률이 100%에 도달했으며 심각한 IO 병목 현상이 발생한 것을 확인할 수 있습니다. 다음 단계는 어떤 프로세스가 이 하드 디스크에 데이터를 읽고 쓰고 있는지 확인하는 것입니다.

2.3 아이오톱

iotop 결과에 따르면, 많은 IO 대기를 발생시키는 Flume 프로세스의 문제를 신속하게 찾아냈습니다.

하지만 처음에 말했듯이 클러스터의 머신 구성도 동일하고 배포된 프로그램도 rsync에서 사용하는 것과 똑같습니다. 혹시 하드 디스크가 고장난 것은 아닐까요?

운영 및 유지보수 학생의 검증이 필요합니다. 최종 결론은 다음과 같습니다.

Sdb는 듀얼 디스크 raid1이며 사용된 raid 카드는 "LSI Logic/Symbios Logic SAS1068E"이며 캐시가 없습니다. 거의 400 IOPS의 압력이 하드웨어 한계에 도달했습니다. 다른 머신에서 사용하는 RAID 카드는 "LSI Logic/Symbios Logic MegaRAID SAS 1078"로, 캐시가 256MB이고 하드웨어 병목 현상이 발생하지 않았습니다. 해결책은 더 큰 IOPS로 머신을 교체하는 것입니다. 통합 RAID 컨트롤러 카드가 있는 PERC6 /i 시스템이 있는 시스템에. RAID 정보는 RAID 카드와 디스크 펌웨어에 저장되어 있으므로 디스크의 RAID 정보와 RAID 카드의 정보 형식이 일치해야 합니다. 그렇지 않으면 RAID 카드가 이를 인식할 수 없으며 디스크가 일치해야 합니다. 포맷되었습니다.

IOPS는 기본적으로 디스크 자체에 따라 다르지만 IOPS를 향상시키는 방법에는 하드웨어 캐시를 추가하고 RAID 어레이를 사용하는 것이 일반적입니다. IOPS가 높은 DB와 같은 시나리오라면 이제 SSD를 사용하여 기존 기계식 하드 디스크를 대체하는 것이 일반적입니다.

그러나 앞서 언급했듯이 소프트웨어와 하드웨어 측면 모두에서 시작하는 목적은 각각 가장 저렴한 솔루션을 찾을 수 있는지 확인하는 것입니다.

이제 하드웨어 이유를 알았으므로 읽기 및 쓰기 작업을 다른 디스크로 이동하여 효과를 확인할 수 있습니다.

3. 마지막 단어: 다른 방법을 찾아보세요

실제로 위에서 언급한 전문 도구를 사용하여 이 문제를 찾는 것 외에도 프로세스 상태를 직접 사용하여 관련 프로세스를 찾을 수 있습니다.

프로세스의 상태는 다음과 같습니다.
•D 중단 없는 절전 모드(보통 IO)
•R 실행 중 또는 실행 가능(실행 대기열에서)
•S 방해할 수 없는 수면(이벤트가 완료되기를 기다리는 중)
•작업 제어 신호에 의해 또는 추적 중이기 때문에 중지되었습니다.
•W 페이징(2.6.xx 커널부터 유효하지 않음)
•X 사망(보여서는 안 됨)
• 존재하지 않는 Z("좀비") 프로세스, 종료되었지만 상위 프로세스에서 회수되지 않음

D 상태는 일반적으로 대기 IO로 인해 발생하는 소위 "중단 불가능한 절전 모드"입니다. 이 지점에서 시작해 단계별로 문제를 찾을 수 있습니다.

위 내용은 새로운 경로 탐색 - IO 대기 진단 도구의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!