Azure Native Qumulo 이제 EU, 영국 및 캐나다에서 사용 가능 – 상세 보기

Windows Storage Offloaded Data Transfer(ODX) 및 프리페치 누락 사례

작성자 :
한 고객이 표준 READ/WRITE와 ODX를 비교할 때 예상보다 느린 성능을 경험한 방법과 엔지니어링 팀이 Qumulo Core의 메트릭, 빠른 릴리스 주기 및 원활한 업그레이드 경험을 활용하여 수수께끼를 풀고 해결한 방법!

한 고객이 표준 READ/WRITE와 ODX를 비교할 때 예상보다 느린 성능을 경험한 방법과 엔지니어링 팀이 Qumulo Core의 메트릭, 빠른 릴리스 주기 및 원활한 업그레이드 경험을 활용하여 수수께끼를 풀고 해결한 방법!

ODX(Windows Storage Offloaded Data Transfer)란 무엇입니까?

Windows Storage Offloaded Data Transfer(ODX)는 서버 메시지 블록(SMB) 프로토콜의 일부로, 클라이언트 컴퓨터를 통해 데이터를 전송하지 않고 파일 청크를 한 파일에서 다른 파일로 복사하도록 Qumulo 파일 시스템에 지시할 수 있습니다. ODX 복사 성능 향상 서버 측 복사(SSC)와 매우 유사합니다. 클라이언트와 서버 간의 네트워크 대기 시간을 제거하고 Qumulo Core가 IO 크기와 버퍼링을 최적화할 수 있도록 합니다. 비교할 때 ODX 대 SSC, 내부 테스트 결과에 따르면 동일한 서버의 다른 위치에 파일을 복사할 때 발생하는 일반적인 READ/WRITE 시퀀스보다 ODX가 7배, SSC가 4배 더 빠릅니다.

대기 시간 미스터리 읽기

2021년에 ODX 지원을 제공했습니다. Qumulo 코어 버전 3.0.0 이상. 우리가 배송된 직후, 고객은 ODX 성능이 예상보다 느리다고 보고했습니다.

ODX가 한 파일에서 읽고 다른 파일에 쓴다는 사실을 알고 있기 때문에 처음에는 쓰기 성능이 문제라고 의심했습니다. 일반적으로 읽기 작업에는 최대 몇 밀리초가 소요됩니다(감사합니다. SSD 캐싱 및 프리페칭!). 그러나 우리가 보았을 때 읽기 대기 시간, 25 또는 40ms에 더 높은 스파이크가 있는 50ms(약) 정도에서 예상보다 ODX 대기 시간의 더 큰 부분이라는 것을 알았습니다. 무슨 일이야? 다음은 ODX 작업의 읽기 단계 수명을 시각화한 것입니다.

우리는 클라우드 모니터링 파이프라인을 통해 수집하는 낮은 세분성 시계열 성능 데이터를 살펴보았습니다. 평균적으로 RAM 캐시 적중률 및 대기 시간 지표는 좋아 보였습니다. 그러나 ODX 특정 읽기가 일반적으로 느린 이유는 무엇입니까?

첫 번째 단서

근본 원인을 밝히는 데 가까워지면서 다른 작업의 소음 없이 이 클러스터의 단일 ODX 워크로드에 특정한 더 높은 세분성 메트릭이 필요했습니다. 운 좋게도 우리에게는 이라는 도구가 있습니다. trigger</var/www/wordpress>, which we built internally, which collects this kind of distributed performance data when needed. We worked with our customer to profile some specific ODX sequences, and used trigger</var/www/wordpress> to collect data during those sequences. We learned a couple of things. (Refer to 그림 1, above.)

각 읽기 작업에서 대부분의 블록은 RAM 캐시에 있었지만 각 읽기에는 몇 블록에 대한 캐시가 누락되었습니다. 이 경우 파일 시스템 트랜잭션은 저장 장치 자체에서 데이터를 읽어야 합니다. 이 경우 메트릭은 데이터가 회전하는 디스크에 있다고 알려줍니다.

[상자 유형 = "그림자"]참고 : 내 마음 속으로 나는 "물론, 그것은 회전하는 디스크 였어야 했어... 항상 회전하는 디스크.” 검색이 대기 시간을 최대 50ms까지 높일 수 있는 유일한 방법이라는 것을 알았어야 했습니다. 회전하는 디스크와 나는 최고의 관계가 없습니다. 그들은 성능에 민감한 코드 경로에서 의도하지 않은 동작을 고통스럽게 노출하는 짜증나지만 유용한 습관을 가지고 있습니다.[/box]

회전 디스크는 요청이 연속 순서로 대기열에 있을 때 데이터를 효율적으로 스트리밍할 수 있습니다. 파일의 시작 부분에서 시작하여 끝까지 읽습니다. 그러나 이 경우 ODX 읽기 작업당 캐시에서 몇 개의 블록만 누락되었습니다. 회전하는 디스크에 많은 불연속 읽기로 표시됩니다. 회전 디스크 대기 시간에 나쁜 소식입니다.

일반적으로 파일 시스템 읽기 작업에는 효과적인 프리페처가 있기 때문에 이러한 종류의 디스크 회전 대기 시간이 발생하지 않습니다. 프리페처는 다음에 읽을 내용을 추측하고 미리 캐시에 로드합니다. 프리페처에는 회전 디스크에서 읽기에 최적화된 IO 패턴이 있습니다.

그렇다면 프리페처가 작동하지 않는 이유는 무엇입니까?

프리페처에는 평균적으로 얼마나 성공적인지 설명하는 지표가 있습니다. 이러한 메트릭은 프리페치되는 모든 항목을 읽고 있지만 파일 시스템에서 읽은 일부 데이터는 프리페치되지 않았음을 나타냅니다. 정말 이상합니다! ODX 작업이 순서대로 읽히지 않거나 임의로 건너뛰는 것일 수 있습니다. 프리페처는 임의 IO와 잘 작동하지 않습니다.

IO 패턴을 보기 위해 작업 로그를 확인했습니다. 작업 로그는 오프셋, 크기, 캐시 적중 또는 누락과 같은 각 작업에 대한 정보를 알려주는 텍스트 로그 파일 도구입니다. 그러나 우리는 작업 로그에 ODX 읽기 크기와 오프셋이 필요하고 그 결과 코드가 연결되지 않을 것이라고 예상하지 못했습니다! 그래서 우리는 더 많은 코드를 작성하고 업그레이드를 기다려야 했습니다…

범인 찾기

몇 주 안에 우리는 새 코드를 배송했고 우리의 매우 멋진 업그레이드를 사용하여 고객은 곧 Qumulo 스토리지 시스템을 최신 버전으로 업그레이드할 수 있었습니다. 그들은 우리를 위해 테스트 워크로드를 다시 실행했습니다. 개선된 작업 로깅을 사용하여 또 다른 퍼즐을 찾았습니다! 작업 로그를 읽음으로써(나는 녹색 숫자가 지나가는 것을 읽는 매트릭스에 있는 것처럼 느꼈습니다) 우리는 ODX 프로토콜 코드가 각각 8650752바이트에 대한 파일 시스템 연속 읽기 요청을 보내고 있음을 발견했습니다. 수학을 해보니 8메비바이트 + 256KiB가 나왔습니다. 하지만! 작업 로그는 각 ODX 요청이 실제로 캐시에서 8388608바이트(정확히 8메비바이트)만 가져오는 것으로 나타났습니다.

나는 처음에 내 눈이 흐릿했던 것을 기억합니다… 내가 숫자를 잘못 읽은 것입니까? 각 요청이 요청한 256MiB 중 8KiB에 대해서만 캐시가 누락된 이유는 무엇입니까? 프리페처는 어떻게 각 요청의 하위 집합만 가져오나요? 불가능합니다!

[상자 유형 = "그림자"]참고 : 모든 버그의 첫 번째 단계는 데이터가 잘못되었다고 믿는 거부입니다. 운 좋게도 이것은 나의 첫 로데오가 아니 었습니다. 나는 재빨리 부인을 억누르고 “어떻게 이것이 가능할 수 있지?”라고 스스로에게 묻기 시작했습니다.[/box]

조사에서 나와 함께 일하고 있던 동료에게 프리페처가 어떻게 작동하는지 설명하기 시작했습니다. 읽기 워크로드의 IO 크기가 중요하지 않도록 프리페처가 읽기 워크로드보다 앞서야 합니다. 프리페처는 항상 큰 청크로 데이터를 가져오며 회전하는 디스크의 대기열이 탐색을 피하기 위해 순서가 정돈되는 방식으로 가져옵니다. 그리고 그것은 나를 때렸다…큰 덩어리...프리페치 청크는 얼마나 큽니까? OH…그들은 8MiB입니다…그건 무시무시합니다. 그리고 어떻게 읽기 워크로드보다 앞서게 될까요? OH, 우리는 읽기 요청당 하나의 프리페치를 시작합니다…잠깐만요…두 가지를 합치면…읽기 요청당 하나의 프리페치를 시작하고 프리페치 청크 크기가 최대 8MiB이고 리더가 8MiB 이상의 청크를 읽는 경우 256KiB...그렇다면 당연히 프리페처는 결코 앞서지 못할 것입니다...항상 다음 8MiB를 프리페치하여 256KiB의 꼬리를 캐싱되지 않은 상태로 둡니다. 와우. (주먹 펌프). 좋아요. 스모킹 건을 찾았습니다.

프리페치 문제의 예시 예시

미스터리 설명

버그를 파악하는 것은 시작에 불과합니다. 즉시 떠오른 세 가지 질문이 있었습니다.

  1. 표준 파일 시스템 읽기 테스트에서 이와 동일한 문제가 발생하지 않는 이유는 무엇입니까?
  2. ODX가 프리페처의 최대 IO 크기보다 큰 8MiB + 256KiB의 IO 크기를 사용하는 이유와
  3. ODX 특정 성능 테스트에서 이를 포착하지 못한 이유는 무엇입니까?
1. 표준 파일 시스템 읽기 성능 테스트에서 이 문제가 발생하지 않는 이유는 무엇입니까?

파일 시스템 프로토콜 스케줄러는 모든 프로토콜 요청을 처리합니다. 일반적인 프로토콜 요청 크기는 1MiB입니다. 프로토콜 읽기 요청을 받으면 이를 처리하고 잠재적으로 읽기 성능을 최적화하기 위해 요청을 결합합니다. 이러한 파일 시스템 요청에 대한 최대 결합 IO 크기는 기본적으로 있습니다. IO 크기가 너무 커지면 요청이 수행하던 큰 단일 스레드 작업(예: CPU, 메모리 할당)에서 요청에 병목 현상이 발생할 수 있습니다. 따라서 파일 시스템 스케줄러는 프리페처의 최대 IO 크기와 동일한 최대 결합 읽기 요청을 8MiB로 만듭니다. 이것은 의도적으로 설계된 것입니다. 따라서 이러한 워크로드에서 프리페처는 모든 것을 프리페치하지만 결합된 IO 크기도 8MiB인 경우 8MiB 이상 앞서지 않습니다…(머리를 긁다...그것도 의도된 동작이 아니었습니다...).

2. ODX가 8MiB + 256KiB의 IO 크기를 사용하는 이유는 무엇입니까?

ODX 작업 자체는 스케줄러를 거치지만 스케줄러를 통해 내부 읽기 요청을 넣지 않습니다. 그런 다음 ODX는 스케줄러와 관계없이 요청하는 최대 IO 읽기 크기를 설정했습니다.

스케줄러의 최대 IO 크기와 ODX 최대 IO 크기가 서로 다른 기능을 사용하고 있음을 발견했습니다.

fs_target_transaction_size()
fs_max_transaction_size()</var/www/wordpress>

스케줄러가 사용 중이었습니다. fs_target_transaction_size</var/www/wordpress>, which is a minimum of fs_max_transaction_size</var/www/wordpress> and 8MiB! Whereas the ODX code was intuitively using fs_max_transaction_size</var/www/wordpress> - which is computed, and turned out to be 8MiB + 256KiB.

그래서 근본 원인이 있었습니다. 사용할 ODX 프로토콜 코드를 수정했습니다. fs_target_transaction_size</var/www/wordpress>, and 짜잔, no more uncached tails to the read requests.

3. ODX의 성능 테스트에서 이를 포착하지 못한 이유는 무엇입니까?

ODX 성능 테스트 , 실제로 캐시되지 않은 꼬리의 동작을 나타냅니다. 그러나 성능은 그렇게 나쁘지 않았습니다. 이 성능 테스트에서 데이터가 SSD 캐시에 들어갈 만큼 작았기 때문입니다!

다시 회상 그림 1 (위) SSD에서 읽기 대기 시간이 회전 디스크보다 훨씬 낮다는 것을 알 수 있습니다. 따라서 프리페처가 잘못된 작업을 수행하고 있다는 것이 최상위 성능 테스트 결과만큼 분명하지 않았습니다. 테스트에서 프리페처의 측정항목을 명시적으로 확인하지 않았습니다.

성능 테스트를 SSD에서 데이터를 제거한 다음 회전 디스크에서 다시 읽는 두 번째 단계를 수행하도록 성능 테스트를 변경한 후, 최상위 성능이 원래보다 훨씬 나빠져 버그가 드러났습니다. 버그를 수정하고 이 자동화된 성능 테스트가 개선되는 것을 관찰했으며 2주 만에 개선품 발송. 다시 한 번 Qumulo의 활용 쉬운 업그레이드, 고객은 수정 후 곧 업그레이드하여 향상된 ODX 성능을 얻을 수 있었습니다.

상세 정보

관련 게시물

위쪽으로 스크롤