오늘 저는 깜박이는 빨간색과 녹색 표시등과 Linux 커널의 PCI Express 드라이버 내부 깊숙한 곳에서 끝난 긴 성능 조사에 대해 이야기할 것입니다.
(또한 아직 못 보신 분들은 꼭 보세요. All-Flash로 가는 길 블로그 시리즈의 두 번째 부분, 내가 이 게시물에서 논의하는 플랫폼을 구축한 사람들에 의해.)
깜박이는 불빛의 발라드.
약 XNUMX년 전에 나는 우리의 새로운 NVMe 올플래시 플랫폼 그리고 이상한 문제가 생겼습니다.
SSD에 장애가 발생하면 드라이브의 작은 빨간색 LED를 켜서 교체해야 할 항목을 표시할 수 없습니다. 이는 NVMe 드라이브가 조명 켜기 및 끄기와 같은 작업을 수행하는 방법을 알고 있는 별도의 컨트롤러에 연결하는 SATA 또는 SAS 드라이브와 달리 PCI-Express를 통해 CPU에 직접 연결되기 때문입니다.
이것은 사소하게 들릴 수 있지만 데이터 센터에서 시각적 피드백을 받는 것은 실제로 고장난 드라이브를 교체해야 하는(그리고 잘못된 드라이브를 교체하지 않아야 하는) 스토리지 관리자에게 중요합니다. 여기에서 가장 좋은 시나리오는 드라이브가 너무 죽어서 LED가 꺼져 있는 것입니다. 최악의 시나리오는 스토리지 관리자가 위험한 미션 임파서블 선택에 직면해 있다는 것입니다. ("빨간 선을 끊어라!" "무슨 빨간 철사? XNUMX개의 전선이 있고 모두 녹색입니다!”)
다행스럽게도 이 문제에는 솔루션이 있으며 그 솔루션을 Intel VMD(볼륨 관리 장치)라고 합니다. VMD는 NVMe 이벤트의 대리자 역할을 하여 소프트웨어 드라이버로 라우팅할 수 있는 특정 Xeon 프로세서의 루트 컴플렉스에 있는 기능입니다. 조명을 켜고 끄는 방법을 아는 것 외에도 더 안정적인 핫 플러깅을 지원합니다.
글쎄.
게임용 PC 녀석들의 말이 맞았다. LED do 영향 성능.
VMD를 사용하도록 설정하면 상황이 느려집니다. ㅏ 많은 더 느리게. 처리량 벤치마크에서 50% 이하의 회귀가 나타났습니다. 최악의 워크로드 중 하나는 이전에 약 15GB/s의 속도를 달성했지만 지금은 6GB/s에 도달하는 데 어려움을 겪습니다.
처음에 우리는 VMD가 작동하는 방식이 SSD에서 얻을 수 있는 처리량을 근본적으로 제한하고 있다고 걱정했습니다. VMD는 일종의 중개자 역할을 하며 그 효과 중 하나는 공유되고 제한된 인터럽트 벡터 세트 뒤에 있는 여러 저장 장치에 앨리어싱을 하는 것입니다. VMD가 없으면 모든 드라이브에는 공유할 필요가 없는 자체 인터럽트 벡터가 있습니다. 우리는 이러한 인터럽트 리소스에 대한 경합이 속도를 늦추는 것이라고 의심했습니다.
그것이 밝혀지면서 우리는 거의 권리.
성능 데이터를 직접 조사하는 동안 문제를 디버깅하는 데 도움을 주기 위해 Intel의 아주 똑똑한 사람들에게도 연락했습니다. 그들의 도움은 이 미스터리의 진정한 범인을 식별하는 데 매우 귀중한 것으로 판명되었습니다.
평균은 오해의 소지가 있으며 기타 명백한 사실
가장 먼저 살펴본 것 중 하나는 두 구성(VMD 꺼짐 및 VMD 켜짐)의 드라이브에 대한 평균 I/O 요청 대기 시간이었습니다. 놀랍게도 평균 지연 시간에는 큰 차이가 없었습니다. VMD가 켜진 상태에서 측정 가능하게 높았지만 약간만 있었습니다. 다음과 같은 그래프(쓰기 테스트 동안 캡처된 데이터에서)는 일반적이었습니다.
요청당 추가 10-15마이크로초는 좋지 않지만 완전히 대기 시간에 묶여 있더라도 50-60% 처리량 손실을 설명하기에 충분하지 않습니다.
한편 인텔 엔지니어들은 드라이버 코드를 자세히 조사하고 있었습니다. 그들이 알고 있었고 사실 우리가 사용하고 있던 것보다 최신 커널 버전에서 이미 수정된 몇 가지 사소한 문제가 있었습니다. 그래서 그들은 우리에게 패치를 제공했고, 우리는 사용자 정의 커널 모듈을 구축했고, 우리는 경주를 떠났습니다. 그러나 이러한 수정은 성능을 약간만 향상시켰습니다.
그들이 발견한 또 다른 문제가 있었습니다. VMD 드라이버는 인터럽트 벡터를 할당할 때 장치의 원하는 CPU 선호도를 적절하게 고려하지 않았습니다. 이 문제를 해결하기 위한 패치에는 VMD가 연결된 각 장치에 할당하려고 시도하는 최대 인터럽트 벡터 수를 제어하는 드라이버 옵션인 max_vec도 추가되었습니다. 기본값은 이전에 4였습니다.
또 다른 패치, 드라이버 재구축의 또 다른 라운드, 그리고 또 다른 테스트 세트 – 그리고 우리가 만족할 정도로 성능이 상당히 향상되었습니다. 하지만 특이한 점도 있었다. max_vec에 대해 다양한 값을 시도하면서 값이 증가함에 따라 성능이 엄격하게 저하된다는 것을 발견했습니다.
| 테스트 처리량 대 max_vec | ||
| max_vec | 쓰다 | 읽기 |
| 2 | 8,080 MB / s의 | 15,460 MB / s의 |
| 4 | 5,540 MB / s의 | 13,670 MB / s의 |
| 8 | 4,540 MB / s의 | 13,430 MB / s의 |
이것은 예상치 못한 일이었습니다. 결국 우리는 데이터를 다시 방문하기로 결정했습니다. 분명히 우리가 놓치고 있는 것이 있었습니다. 나는 수많은 성능 테스트에서 iostat 데이터를 살펴보기 시작했고 곧 누락된 부분을 발견했습니다. 드라이브 조금 느리지 않았다. 정확히 한 드라이브는 많이 더 느림:
인텔 엔지니어에게 이 플롯을 보여주었을 때 그는 "유레카" 순간 중 하나를 경험했습니다. 문제는 결국 VMD에 있는 것이 아니라 Microsemi PCIe 스위치에 내장된 관리 모듈인 완전히 별도의 PCIe 장치용 드라이버에 있었습니다.
VMD가 일종의 중개자 역할을 하고 공유된 인터럽트 벡터 세트를 통해 연결된 장치를 관리하는 방법을 기억하십니까? VMD는 이러한 벡터 중 하나에서 인터럽트를 수신할 때 어떤 장치가 실제 대상인지 반드시 알 필요는 없습니다. 따라서 실제로 인터럽트 핸들러를 호출해야 합니다. 모든 해당 벡터를 공유하는 장치. 이러한 인터럽트 처리기 중 하나가 다른 것보다 느리면 나머지는 그냥 강제로 기다려야 합니다.
바로 그 일이 일어났습니다. max_vec를 2 이상으로 늘리면 상황이 극적으로 악화되는 이유는 각 장치에 더 많은 인터럽트 벡터를 할당하면 SSD 중 하나(또는 그 이상!)가 Microsemi 스위치와 벡터를 공유하게 될 확률이 증가하기 때문입니다. 또한 Qumulo 파일 시스템의 단일 쓰기 작업은 데이터 보호를 위해 여러 저장 장치에 걸쳐 삭제 코딩되므로 쓰기에 관련된 디스크 하나만 느리면 전체 쓰기가 느려집니다.
다음은 문제가 되는 인터럽트 핸들러의 압축된 버전입니다. Linux 커널 소스의 drivers/pci/switch/switchtec.c:
정적 irqreturn_t switchtec_event_isr(int irq, 무효 *dev)
{
구조 switchtec_dev *stdev = dev;
u32 등록;
/* ... */
등록 = ioread32(&stdev->mmio_part_cfg->mrpc_comp_hdr);
if (reg & SWITCHTEC_EVENT_OCCURRED) {
/* ... */
iowrite32(reg, &stdev->mmio_part_cfg->mrpc_comp_hdr);
}
/* ... */
}
스위치 장치 자체의 메모리 매핑된 I/O 주소를 대상으로 하는 ioread32 및 iowrite32에 대한 호출을 확인하십시오. 인터럽트 처리의 일부로 이 드라이버는 PCIe 버스(!)를 통해 실제 I/O를 수행합니다.
장치 드라이버 작성에 대한 단 하나의 계명이 있다면 강력한 경쟁자는 "인터럽트 핸들러에서 절대적으로 필요한 것보다 더 많은 작업을 수행하지 마십시오"일 것입니다. 이 장치에서는 I/O를 기다리는 것이 큰 문제가 아닐 수도 있지만, 대기 시간에 매우 민감한 무언가와 인터럽트 벡터를 공유하게 되면 큰 문제가 됩니다!
운 좋게도 이 전체 문제에 대한 해결책은 간단했습니다. switchtec 커널 모듈을 로드하지 마십시오. 우리는 그 어떤 기능도 필요로 하지 않았으며, 느린 인터럽트 핸들러가 혼합되어 있지 않았기 때문에 백업되어 최고 속도로 실행되었습니다. 과 우리의 깜박이는 화려한 조명.
이 이야기의 교훈
이상치는 매우 중요할 수 있습니다.
이것은 거의 모든 사람이 "알고 있는" 것 중 하나이지만, 특히 가설을 쫓을 때 잊기 쉽습니다. 평균은 결국 유용합니다. 하나의 숫자로 현상에 대해 많은 것을 알 수 있습니다. 그러나 기본 분포를 이해하지 못한다면 평균에서 너무 많은 결론을 도출하지 마십시오!
