“누마, 누마이에이”
– 단 미하이 발란
이전에 Linux 파일 시스템을 관리해 본 사람이라면 누구나 알겠지만 Linux 커널의 새 버전으로 업그레이드하는 것은 일반적으로 그리 어렵지 않지만 때로는 놀라운 성능 영향을 미칠 수 있습니다. 이것은 그 중 하나의 이야기입니다.
쿠물로스 파일 시스템 소프트웨어 꽤 표준적인 Ubuntu 배포판 위에 배송됩니다. 우리는 정기적으로 배포판과 기본 Linux 커널을 업데이트하여 장기간 지원되는 버전을 유지하므로 최신 보안 업데이트 및 버그 수정을 계속 확인하고 최신 저장 장치를 지원할 수 있습니다.
우리는 최근에 Linux 5.4를 사용하도록 모든 플랫폼을 업데이트했습니다. 이전에는 일부는 4.4에, 일부는 4.15에 있었습니다. 대부분의 경우 모든 것이 순조롭게 진행되었습니다. 그러나 새 커널을 사용한 성능 테스트에서 이상한 점을 발견했습니다. 4U 듀얼 인텔 CPU Qumulo 시스템(고객에게 Qumulo QC104, QC208, QC260 및 QC360 시스템으로 알려짐)의 처리량이 많이 떨어졌습니다. 쓰기 스트림이 많은 한 테스트에서 처리량은 ~4.5GB/s에서 약 3.2GB/s로 거의 30% 감소했습니다!
이러한 시스템은 이중 프로세서 Haswell을 사용합니다. 많은 고객이 데이터를 관리하기 위해 의존하는 대규모 활성 배포를 가지고 있습니다. 우리는 시간이 지남에 따라 플랫폼이 느려지는 것이 아니라 더 빠르게 만들기 위해 지속적으로 노력하고 있습니다!
이제 소프트웨어를 더 느리게 실행하게 만든 원인을 파악하고 수정해야 할 때였습니다.
Linux 성능 문제 모니터링, 문제 해결 및 진단
모든 종류의 성능 문제를 진단할 때 일반적으로 성능 카운터, 대기 시간 측정 및 파일 시스템 내 계측에 의해 생성된 기타 메트릭을 살펴보는 것으로 시작합니다. 이와 같은 Linux 성능 모니터링 도구를 사용하면 시스템이 시간을 소비하는 위치를 쉽게 분석하고 문제의 원인을 보다 정확하게 진단할 수 있습니다. 이 경우 메트릭은 디스크 I/O가 정상이고 CPU 사용량이 정상이지만 네트워킹에 훨씬 더 많은 시간이 소요된다는 명확한 이야기를 했습니다.
따라서 업그레이드의 일부로 크게 변경되었을 수 있는 네트워크와 관련된 모든 것을 자세히 살펴봐야 했습니다. 운 좋게도 커널 코드를 파헤치는 수고를 덜었습니다. 한 가지 주요 용의자를 즉시 찾았기 때문입니다. Linux 5.4로 업그레이드하는 것 외에도 이더넷 드라이버를 변경했습니다. 이전에는 Mellanox NIC에 OFED를 사용했지만 지금은 커널에 포함된 버전을 사용하고 있습니다.
성능 저하의 실제 원인은 작은 구성 변경이었기 때문에 드라이버 코드의 세부 사항도 중요하지 않은 것으로 나타났습니다. OFED에는 네트워킹 인터럽트를 가장 가까운 CPU에 자동으로 선호하는 스크립트가 포함되어 있지만 기본 드라이버는 그렇지 않습니다. 스크립트를 다시 도입하거나 수동으로 선호도를 설정하면 즉시 모든 처리량이 다시 돌아옵니다.
그래서 우리는 답을 얻었고 약간의 조정으로 커널 5.4가 포함된 새 배포판을 고객에게 자신 있게 배송할 수 있었습니다.
NUMA 관련 성능 병목 현상 해결
우리는 단순히 문제를 해결할 수 있는 것으로 만족하지 않습니다. 우리는 원한다 이해 그들의 근본적인 원인. 그리고 이 경우에는 뭔가 이상해 보였습니다. NUMA 시스템(비균일 메모리 액세스 시스템)에서는 일반적으로 인터럽트를 로컬로 선호하는 것이 더 좋지만 고려 중인 처리량 수준(특정 노드에서 몇 GB/s만)에서는 다음과 같은 통신이 의미가 없습니다. CPU가 병목 현상이 될 수 있습니다.
아래 다이어그램은 아키텍처의 단순화된 그림을 보여줍니다. 5개의 Xeon E2620-3 v128 CPU, XNUMXGB RAM 및 여러 디스크가 있습니다.
두 CPU 간의 링크에 유의하십시오. 이는 QPI(QuickPath Interconnect) 채널로, 한 CPU가 다른 CPU에서만 사용할 수 있는 데이터가 필요할 때마다 사용됩니다. 예를 들어 CPU 1이 네트워크에서 수신한 데이터를 처리해야 하는 경우 데이터는 QPI를 통과해야 합니다. .
[상자 유형 = "그림자"]QuickPath 상호 연결이란 무엇입니까?
QuickPath Interconnect는 2008년에 처음 도입된 일부 Intel 마이크로아키텍처의 CPU와 다른 마더보드 리소스(예: IO 허브 또는 다른 CPU) 간의 데이터 연결입니다. 모두 시스템 리소스를 최대한 활용할 수 없다면 하나의 마더보드에 더 많은 CPU를 배치하는 것은 의미가 없습니다. (Skylake 마이크로아키텍처가 출시되면서 2017년 UltraPath Interconnect라는 새 버전으로 대체되었습니다.)[/box]
E5-2620 v3에는 16개의 XNUMX비트 QuickPath 상호 연결 채널이 있습니다. 4GHz에서 클럭. 각 채널은 상승 및 하강 클록 에지 모두에서 데이터를 전송하므로 초당 8GT(기가 전송) 또는 양방향으로 16GB/s의 대역폭이 발생합니다. 따라서 그 중 두 개를 사용하면 이 링크가 병목 현상이 되기 전에 32GB/s에 가까워야 합니다. 이는 NIC 및 저장 장치의 상대적으로 적당한 요구 사항을 처리하기에 충분합니다!
그러나 분명히 병목 현상이 발생했으며 CPU 간 통신을 피하기 위한 조치를 취했을 때 병목 현상이 사라졌습니다. 무슨 일이 있었던 걸까요?
예를 들어 NFS 프로토콜을 사용하여 Qumulo 노드가 데이터 읽기 요청을 처리할 때 어떤 일이 발생해야 하는지 살펴보겠습니다. 아래 다이어그램은 데이터 흐름의 단순화된 버전을 보여줍니다.
- 일부 데이터는 다른 노드(파란색 화살표)에서 가져와야 합니다. 이 데이터는 NIC에 일련의 TCP 세그먼트로 도착한 다음 DMA를 통해 커널의 링 버퍼로 오프로드되고 거기에서 Qumulo 파일 시스템의 내부 페이지 버퍼로 오프로드됩니다.
- 이 노드에서 일부 데이터를 가져옵니다(보라색 화살표). 이것은 디스크에서 읽고 페이지 버퍼에 복사됩니다.
- 로컬 데이터와 원격 데이터가 수집되면 프로토콜 작업자는 이 모든 것을 응답으로 조합한 다음 전송 버퍼에 넣습니다. 이 데이터는 NIC로 DMA되고 네트워크를 통해 요청하는 클라이언트로 전달됩니다. .
양파의 중심에 도달하기
여기서 중요한 통찰력은 위의 순서도에서 각 화살표(NIC를 나가는 화살표 제외)는 데이터가 QPI 링크를 통과할 수 있는 지점을 나타냅니다(때로는 두 번 이상).
예를 들어 아키텍처 다이어그램에서 두 CPU에 연결된 저장 장치가 있다는 것을 상기하십시오. CPU 0이 CPU 1에 연결된 디스크에서 1GB의 데이터를 읽은 다음 CPU 1에 연결된 메모리에 매핑된 페이지 버퍼 영역에 복사하면 해당 데이터는 링크를 두 번 교차합니다. 데이터를 처리하는 프로토콜 작업자는 CPU 0에서 실행될 수 있으며 링크를 다시 건너는 데 동일한 데이터가 필요한 식입니다.
따라서 "증폭 효과"가 발생합니다. 노드가 2GB/s의 속도로 데이터를 제공하더라도 동일한 데이터가 다음과 같이 앞뒤로 바운스되기 때문에 QuickPath Interconnect에 몇 배나 많은 트래픽이 발생할 수 있습니다. 데이터 테니스 게임:
NUMA 관련 성능 병목 현상의 실제 원인 식별
하지만 잠깐, 당신이 말하는 것을 들었습니다! 가장 비관적인 시나리오에서도 이 증폭은 2GB/s를 32GB/s로 변환할 수 없으며 해당 그래프에서 NUMA 경계를 가로지르는 가장자리가 충분하지 않습니다!
그것은 사실입니다. 우리는 링크의 정격 속도보다 훨씬 낮은 병목 현상에 직면해 있는 것 같았습니다. 다행히 인텔은 메모리 지연 검사기 (Intel MLC라고도 함) 시스템의 실제 성능을 직접 측정할 수 있으므로 실행하여 다음과 같은 의심을 확인했습니다.
Measuring Memory Bandwidths between nodes within system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
Numa node
Numa node 0 1
0 46242.9 6291.7
1 6276.3 46268.6</var/www/wordpress>CPU 0은 ~46GB/s의 속도로 직접 연결된 RAM에 액세스할 수 있었고 CPU 1도 마찬가지였습니다. 하지만 둘 중 하나가 다른 CPU에 연결된 메모리에 액세스하려는 순간에는 약 6GB/s가 그들이 할 수 있는 최선이었습니다. .
이 시점에서 Intel의 Haswell 아키텍처에 매우 익숙하다면 무슨 일이 일어나고 있는지 이미 알고 있을 것입니다. 저희는 특별히 없었기에 구글링으로 증상을 찾아보았고, 그 결과 정답을 얻었습니다. 인텔 커뮤니티 스레드. 간단히 BIOS로 이동하여 "스눕 모드"를 "초기 스눕"에서 "홈 스눕"으로 변경하면 병목 현상이 사라집니다!
그래서 도대체 초기 스눕이 무엇입니까? 불행히도 초기 스눕은 만화 비글이나 모닝 커피를 마시는 특정 미국 래퍼와 아무 관련이 없습니다. 대신 컴퓨터 과학에서 가장 어려운 두 가지 문제 중 하나에 대해 이야기해야 합니다. 캐시 일관성. (나머지 두 개는 이름 지정 및 오프 바이 원 오류입니다.) MESI를 얻으려고 합니다. 특히 스누핑은 MESI 프로토콜의 일부이며 Intel 프로세서에서 사용하는 MESIF 변형의 확장입니다.
MESI 캐시 일관성 프로토콜
MESI는 캐시 일관성을 강화하기 위한 공통 프로토콜입니다. 즉, 시스템의 모든 다른 캐시가 메모리 내용에 대한 일관된 보기를 갖습니다. MESI는 모든 캐시의 모든 라인에 XNUMX가지 상태 중 하나를 할당하여 작동하며, 캐시 라인을 사용할 수 있는 방법을 결정합니다.
- 수정: 라인이 변경되어 더 이상 메인 메모리에 있는 것과 일치하지 않습니다.
- 독점: 라인이 메인 메모리와 일치하고 이 캐시에만 존재합니다.
- 공유: 행이 수정되지 않았지만 다른 캐시에 있을 수 있습니다.
- 잘못된: 라인이 사용되지 않거나 무효화되었습니다(예: 다른 캐시의 복사본이 수정됨).
MESI 대 MESIF
MESIF는 Intel에서 개발한 MESI의 확장입니다. 다섯 번째 상태인 "앞으로"를 나타내는 F를 추가합니다. Forward는 Shared와 유사하지만 시스템의 한 캐시에만 Forward 상태의 라인이 있을 수 있습니다. 이는 대부분 시스템에서 캐시 라인을 요청할 때 과도한 응답을 피하기 위한 최적화입니다. 회선의 사본을 보유하고 있는 모든 캐시가 응답하는 대신 회선을 F 상태로 보유하고 있는 캐시만 응답합니다.
MESI와 MESIF 모두에서 중요한 변경 사항이 발생할 때 버스를 통한 알림을 통해 다양한 캐시가 일관성 있게 유지됩니다.
초기 스눕 대 홈 스눕
이러한 고려 사항이 성능에 중요한 이유는 Intel의 Haswell 아키텍처의 캐시 레이아웃과 관련이 있습니다. 각 패키지의 공유된 마지막 레벨 캐시(LLC)는 매우 높은 대역폭의 온다이 링에 연결된 코어당 하나씩 여러 슬라이스로 나뉩니다. 각 캐시 슬라이스에는 자체 캐시 "에이전트"가 있습니다. 각 메모리 컨트롤러에 대한 "홈 에이전트"도 있습니다.
"early snoop" 모드(위에 표시된 CPU 5개)에서 캐시 미스 또는 캐시 일관성 이벤트가 발생하면 시작 캐시 에이전트가 시스템의 다른 모든 캐시 에이전트에 메시지를 브로드캐스트합니다. 이는 캐시 라인의 상태를 해결하는 데 필요한 시간을 줄여 액세스 대기 시간을 줄이기 위한 것이지만 원격 CPU의 모든 캐시 에이전트가 QuickPath Interconnect를 통해 응답하므로 일관성 채터가 사용 가능한 노드 간 메모리 대역폭을 크게 줄일 수 있습니다. 분명히 Haswell-EP E2620-3 v75를 사용하면 대역폭의 XNUMX%를 잃을 수 있습니다.
대조적으로 "홈 스누프" 모드에서는 메시지가 각 메모리 컨트롤러의 홈 에이전트에 의해 먼저 처리된 다음 필요에 따라 LLC 에이전트에 위임됩니다. 추가 홉은 약간의 대기 시간을 추가하지만 처리량이 크게 증가하는 이점이 있습니다. QuickPath Interconnect를 통해 전송되는 메시지가 훨씬 적다는 점에 유의하십시오.
만나다 이 게시물에 NUMA 캐시 일관성에 대한 자세한 설명은
그렇다면 홈 스눕이 얼마나 더 나은가요?
테스트 클러스터의 모든 시스템에서 snoop 모드가 변경되면서 Memory Latency Checker는 CPU 간의 처리량이 크게 향상되었음을 보여주었습니다.
Measuring Memory Bandwidths between nodes within system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
Numa node
Numa node 0 1
0 45139.0 25323.8
1 25336.2 45021.7</var/www/wordpress>그러나 더 좋은 점은 이 병목 현상을 완화하면 이러한 시스템의 성능도 크게 향상된다는 것입니다. 인터럽트 선호도가 손실되었을 때 관찰되는 30% 회귀를 제거했을 뿐만 아니라 추가 처리량이 30% 더 추가되었습니다.
| 테스트(4노드, QC208) | 기준선(초기 스눕) | 홈 스눕 | 변화 |
| 쓰기 처리량 | 4400MB/ | 6000MB/ | 36% |
| 읽기 처리량 | 7650 MB / s의 | 9550MB/초/초 | 29% |
저는 XNUMX~XNUMX년 전, Qumulo에서 경력을 쌓기 시작한 초기에 이 플랫폼에서 처음으로 성능 문제를 해결했던 것을 기억합니다. 그 당시 snoop 모드로 실험했던 기억이 어렴풋이 납니다. 당시에는 큰 차이가 없었습니다. 그러나 수년에 걸쳐 소프트웨어 병목 현상을 제거하여 성능을 지속적으로 개선함에 따라 기본 하드웨어 플랫폼의 성능이 제한 요소가 되었기 때문에 QuickPath Interconnect 처리량 제한을 높이는 것이 큰 승리가 되었습니다.
그래서 다음 릴리즈에서는 Qumulo 코어, 우리는 영향을 받는 모든 모델에 대해 BIOS에서 이 설정을 뒤집는 코드를 추가하여 기존 배포를 사용하는 모든 고객이 더 큰 처리량 용량의 이점을 누릴 수 있도록 했습니다.
파일 시스템의 성능을 개선하기 위해 Qumulo에서 훨씬 더 많은 훌륭한 작업이 수행되고 있습니다. 대부분은 숨겨진 "빠르게 가기" 스위치를 찾는 것보다 훨씬 더 어렵습니다(더욱 흥미롭습니다). 그러니 이 공간을 계속 주시하세요!
Qumulo에서 엔지니어링에 대해 자세히 알아보고 싶으신가요? Qumulo 엔지니어가 작성한 게시물 더 보기 여기에서 지금 확인해 보세요.. 또는 다음을 살펴보십시오. Qumulo 데이터 플랫폼 - 소프트웨어 아키텍처 개요(PDF).
더 읽기
- fio 사용 관련 이야기: 일관된 성능 측정을 위한 3단계
- Qumulo 코어 아키텍처에 대한 짧은 시리즈: 하드웨어 유연성을 염두에 두고 구축 (파트 1)
- 스토리 팔로우: Hardware Agnostic Enterprise 파일 스토리지 구축 (파트 2)
