데이터 이동기가있는 Linux I / O 병목 현상

Ubuntu 서버 10.04를 실행하는 94.6GiB RAM이 장착 된 24 코어 시스템이 있습니다. 동일한 유형 및 양의 프로세스를 실행하는 다른 서버 (4 코어)와 달리이 상자는 % iowait가 높습니다. 두 머신은 VNX Raid 파일 서버, 24 개의 FC 머신은 4 개의 FC 카드를 통해, 다른 머신은 2 기가비트 이더넷 카드를 통해 연결됩니다. 4 코어 시스템은 현재 24 코어 시스템보다 성능이 뛰어나고 CPU 사용량이 높으며 % iowait는 낮습니다.

가동 시간 9 일 동안 % iowait는 평균 16 %이며 일반적으로 30 % 이상입니다. 대부분의 경우 CPU 사용량은 매우 낮으며 약 5 %입니다 (높은 iowait로 인해). 충분한 여유 메모리가 있습니다.

내가 이해하지 못하는 한 가지는 모든 데이터가 데이터 이동기를 직접 거치지 않고 장치 sdc를 통과하는 것처럼 보이는 이유입니다.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.11    0.39    0.75   16.01    0.00   76.74

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               0.00         0.00         0.00       1232          0
sdb               0.00         0.00         0.00       2960          0
sdc               1.53        43.71        44.54   36726612   37425026
dm-0              0.43        27.69         0.32   23269498     268696
dm-1              1.00         1.86         7.74    1566234    6500432
dm-2              0.96         1.72         5.97    1442482    5014376
dm-3              0.49         9.57         0.18    8040490     153272
dm-4              0.00         0.00         0.00       1794         24
dm-5              0.00         0.00         0.00        296          0

퍼즐의 또 다른 부분은 작업이 종종 io holdup으로 인해 상호 작용할 수없는 절전 모드 (위쪽)로 들어가는 것입니다.

문제 진단을 돕기 위해 무엇을 볼 수 있습니까? 모든 데이터가 왜 / dev / sdc를 통과합니까? 그게 정상인가요?

최신 정보:

네트워크 연결 및 VNX 읽기 / 쓰기 용량이 병목 현상으로 배제되었습니다. 4 개의 본드 된 NIC (라운드 로빈)로 800MB / s의 속도에 도달 할 수 있습니다. 파이버 채널 카드는 아직 사용되지 않습니다. VNX는 IO (RAID6, 풀당 30x2TB 7.2kRPM 디스크 2 개 풀 (전체 60 디스크), 약 60 % 읽기)를 처리 할 수 ​​있습니다.

dm 및 sdc에 대해서는 위에서 무시하십시오. 이들은 모두 내부 디스크이며 문제의 일부는 아닙니다.

우리는 nfs 마운트 나 TCP (VNX에 5 개의 마운트와 5 개의 파티션이 있음)에 문제가 있다고 생각하지만 정확히 무엇인지 모릅니다. 어떤 충고?

우선 CPU가 데이터 저장 공간을 제공 할 수있는 것보다 더 빨리 데이터를 먹는다면 (오 히트 24) 그것은 블로킹 io (읽기 속도가 너무 느리거나 동기 쓰기) 중에 커널이 프로세스를 일시 중지시키는 시점입니다.
따라서 스토리지가 24 코어에 충분한 처리량을 제공 할 수 있는지 확인하십시오.

예를 들어, 스토리지가 500MB / s 처리량을 제공 할 수 있고 2 기가비트 이더넷 회선 (본드)을 통해 연결되어 있고 네트워크가 이미 최대 처리량을 약 100-180MB / s로 제한한다고 가정합니다. 프로세스가 50MB / s의 속도로 데이터를 먹고 4 개의 코어 시스템에서 4 개의 스레드를 실행하는 경우 : 4 x 50MB / s = 200MB / s가 소비됩니다. 네트워크가 180MB / s를 유지할 수 있다면 대기 시간이 많지 않고 CPU가로드됩니다. 여기의 네트워크는 작은 병목 현상입니다.
이제 최대 24 개의 코어와 24 개의 스레드로 확장 할 경우 1200MB / s가 필요합니다. 이러한 처리량을 허용하도록 배선을 변경하더라도 스토리지 시스템이 500MB / s를 초과하지 않으면 병목 현상이 발생합니다.

기다릴 때 병목 현상이 어디에나 발생할 수 있습니다. 물리적 계층뿐만 아니라 소프트웨어 및 커널 공간 버퍼에서도. 사용 패턴에 따라 다릅니다. 그러나 소프트웨어 병목 현상을 식별하기가 훨씬 어려우므로 일반적으로 소프트웨어 스택을 조사하기 전에 하드웨어의 이론적 처리량을 확인하는 것이 좋습니다.

앞서 언급했듯이, iowait는 프로세스가 읽기를 수행하고 데이터가 도착하는 데 시간이 걸리거나 동기화 쓰기를 수행하고 데이터 수정 승인에 시간이 걸리는 경우 발생합니다. 동기화 쓰기 중에 프로세스는 무정전 절전 모드로 전환되므로 데이터가 손상되지 않습니다. 프로세스를 중단시키는 호출을 확인하는 편리한 도구가 있습니다 latencytop. 그것은 유일한 종류는 아니지만 시도해 볼 수 있습니다.

참고 : dm은 데이터 이동기가 아니라 장치 매퍼를 나타냅니다.

우선, 철분이 많은 거룩한 지옥! :)

불행히도 설정이 매우 복잡하게 들리므로 누군가 "직접 문제가 있습니다!" 그들이 매우 유사하거나 동일한 설정으로 무언가를하지 않고 동일한 문제가 발생하지 않는 한 대답하십시오. 따라서이 텍스트에는 SU로 "답변"이라는 레이블이 붙어 있지만 "제안"처럼 생각해야합니다. 그리고 단어가 너무 많아 주석에 넣을 수 없습니다. :에스

하드웨어가 장치에 어떻게 매핑되는지에 대한 지식이 없으면 I / O가 다른 곳이 아닌 다른 곳으로가는 이유를 말하기가 어렵습니다. 장치를 어떻게 장착합니까? 프로그램이 sd*장치에 직접 액세스합니까 , 아니면 모든 파일 시스템이 dm장치에 마운트되어 있고 모든 파일 액세스가이 장치를 통해 발생합니까?

내가 물어봐야 할 다른 것들 :

• 어떤 종류의 RAID입니까? RAID5 또는 RAID6으로 패리티 비트를 계산하는 경우 RAID 서버 하드웨어에 의해 처리 될 것입니다. 그렇지 않은 경우 처리 서버가이를 수행하고 있습니다. 소프트웨어에서 수행됩니다.

• 메시지에서 두 서버의 주요 차이점 중 하나를 분리했습니다. 하나는 파이버 채널을 사용하고 다른 하나는 이더넷을 사용합니다. 파이버 채널 은 더 나은 대기 시간과 대역폭을 제공 해야 하지만 문제이기도합니다. 많은 처리량을 제공하는 경우 RAID 서버 자체를 매우 바쁘게 만들 수 있습니다. 혼잡으로 인해 버퍼 / 캐시가 채워집니다 대기 시간이 증가하여 I / O 대기 시간이 늘어납니다.

그것은 당신이 거의처럼의 수 디스크 배열을 버퍼 팽창 문제가 - 당신은 알아? 하드웨어 RAID 컨트롤러는 일반적으로 많은 온보드 캐시를 가지고 있습니다. 따라서 미디어에 대한 I / O가 대기열에 들어가고 캐시가 더티 페이지로 가득 차게되면 결국 모든 것이 포화되고 (기계적 스토리지가로드를 견딜 수없는 경우) 대기 시간이 지붕을 통과합니다. 4 코어 + GbE보다 24 코어 + FC로 더 많은 부하를 생성 할 수 있습니다. :) RAID 서버를 점검하고 디스크 사용량이 많은지 확인하십시오. 많은 "I / O"는 제어 패킷 등일 수 있습니다. I FC가 어떻게 작동하는지 확실하지 않지만 TCP와 같은 것이면 대기 시간이 너무 높으면 재전송이 표시됩니다.

전화로 누군가에게 질문을하고 몇 초 동안 응답하지 않으면 "안녕하세요?"라고 말합니다. -네트워킹 프로토콜 (및 FC는 네트워킹 프로토콜 일뿐)은 짧은 시간 단위로 동일한 작업을 수행합니다. 그러나 물론 그 "여보세요?" 이미 혼잡 한 파이프에 더 많은 데이터를 추가하기 때문에 네트워킹과 관련하여 비용이 많이 듭니다.

마지막으로 일반적인 팁 :

대기 시간 / IO 대기 / 처리량 문제를 디버깅 할 때는 항상을 측정하십시오 . 어디서나 측정하십시오. 와이어에서 측정하고, 프로그램 자체에서 수행하는 작업을 측정하고, 처리 종료에서 측정하고, RAID 서버에서 측정하는 등 하나의 관점에서 보지 말고 시스템의 각 개별 구성 요소를 고려하십시오. 파이프 라인의 데이터를 처리, 읽기 또는 쓰기를 담당합니다. 하나의 트랜잭션 또는 하나의 개별 작업 단위를 분리하고 하드웨어를 통과하는 경로를 정확하게 해체하고 각 개별 구성 요소에서 병목 현상이 있거나 지연 시간이 과도한 장소 등이 있는지 확인합니다. 양파를 되돌릴 수 있습니다.”라는 문구를 사용하여 데이터 흐름을 디버깅하는 작업을 참조했습니다.

작은 추가. 이 경우 블록 레벨 튜닝 및 I / O 스케줄러를 살펴볼 수 있습니다. 나는 우분투에 익숙하지는 않지만 많은 양의 저장 성능 조절 장치가 있습니다. 이것은 SAN 스토리지 및 데이터베이스의 경우에 반드시 적용됩니다.

• 시스템 I / O 스케줄러를 살펴보십시오 . CFQ 는 기본값이지만 데이터베이스 워크로드에는 noop 및 데드 라인 이 일반적으로 선택됩니다.
• 도움이 될만한 다른 튜닝 매개 변수에 대해서는 이 링크 를 참조하십시오 .
• NFS 및 블록 스토리지를 언급했습니다. 차단 된 경우 어떤 파일 시스템을 사용하고 있습니까? 여기에서 I / O 대기는 쓰기 차단 상황처럼 들립니다. 쓰기 장벽이 활성화되어 있습니까? 로 파일 시스템을 다시 마운트하십시오 nobarrier. ( 우분투 힌트 )

일부 관련 서버 오류 링크 ...

Linux-실제 하드웨어 RAID 컨트롤러 튜닝 (scsi 및 cciss)

아이디어와 의견을 보내 주셔서 감사합니다. 이 문제는 VNX 자체의 결함있는 I / O 모듈과 결합 된 비 최적 이더넷 본딩 구성의 조합과 관련이 있습니다. I / O 비율은 이제 예상치에 가깝습니다. dd 파일 쓰기 및 읽기 테스트와 iozone 벤치 마크에서이를 감지 할 수 없었으며 예상대로 빠르게 읽고 쓸 수있었습니다.

나는 더 많은 정보로 곧 편집 할 것이지만, 먼저 iostat의 dm- * 출력이 당신을 혼란스럽게해서는 안된다고 말하고 싶습니다. Device-mapper는 md * (md0, md1 등)와 같은 커널 내부 경유 장치이므로 기본 장치에만 관심이 있습니다. 디스크로 전달되는 모든 데이터는 도중에 dm / md를 거치며 실제 총계 (바이트, 초 등)는 정확하지만 util은 오해의 소지가 있습니다.

또한, 그것은 매우 많은 양의 메모리입니다. 특히 하나의 프로세스가 램의 절반 이상을 차지하는 경우 재미있는 일이 시작됩니다 (나는 스스로 2x64 및 2x96을 실행합니다). 자세한 내용은이 기사를 읽으십시오 . 이 기사에서는 mysql에 대해 언급했지만 그렇지 않습니다.MySQL 특정. 모든 소프트웨어 프로세스는 다른 물리적 프로세서의 액세스 메모리에 대한 벌칙을 내립니다. 48gb는 한 프로세스에 속한다고 생각합니다. 프로세스는 하나의 프로세스에만 속할 수 있으며 다른 프로세스 메모리에 도달하려면 (48GB가 소진 된 후) 프로세스 중 일부를 스왑에 저장하거나 다른 가격으로 지불하기로 결정해야합니다. 다른 proc의 메모리. 이 기사에서는 numactl 명령을 실행하여 소프트웨어가 스왑하지 않고 페널티를 지불하도록 강요합니다. 나는 개인적으로 이것으로부터 엄청난 개선을 보았습니다. 다시 말해, 일부 I / O가 교체되는지 확인하십시오! 이것을 위해 free -m (또는 이와 유사한)을 사용하십시오. 사용 가능한 메모리가 충분하지만 사소한 양의 스왑 페이지 (예 : 10 % 이상)가있는 경우 문제가 될 수 있습니다.

스토리지 관점에서이를 살펴보면 scsi 대기 시간을 측정 할 수있는 방법이 있습니까? OS io 대기 시간에는 스토리지 제어 외부의 많은 것들이 포함되지만 스토리지 박스에 들어가서 2ms의 IO 대기 시간을 볼 때 서버가 내부적으로 가져 오는 것과 상관없이 scsi 명령이 응답한다는 것을 알고 있습니다 스토리지를 변수로 제거 할 수 있습니다.