DPC 지연이 높다고 VPN 경로가 느린 것은 아니다

오디오 결함과 VPN 일시 중지가 같은 십 초 안에 일어나고, 한 유틸리티가 DPC 지연이라는 라벨을 붙인 높은 수치를 보고한다. 드라이버가 터널을 느리게 한다거나 터널이 드라이버에 부담을 준다고 결론 내리고 싶어진다. 그 수치에서 두 결론 중 어느 것도 따라 나오지 않는다.

여기에는 세 가지 측정이 얽혀 있고, 그것들은 같은 경계를 공유하지 않는다.

세 숫자, 세 경계

지연된 프로시저 호출은 드라이버가 인터럽트 핸들러에서 미루는 작업이며, 그 루틴 안에서 쓰는 시간은 모듈과 함수에 귀속되는 프로세서 로컬 측정이다. 에코 왕복은 소켓에서의 시간 관측이며, 네트워크 스택과 원격 응답자가 만들어 낸다. 연결 끊김 이벤트는 클라이언트가 기록하는 상태 전이이다. 각각은 다른 것들이 답할 수 없는 질문에 답하며, 단위가 같다고 해서 서로 바꿔 쓸 수 있는 것은 아니다.

유용한 규율은 값을 읽기 전에 경계를 먼저 이름 붙이는 것이다. 단위와 경계를 나란히 적어라. 도구가 밀리초를 보고하면 무엇의 밀리초인지 물어라. 루틴 내부의 시간인지, 실행을 기다린 시간인지, 응답이 도착할 때까지의 시간인지.

한 범주의 높은 숫자는 단서일 뿐, 결코 진단이 아니다.

헤드라인 뒤의 정의를 읽어라

유틸리티마다 지연이라고 부르는 대상이 다르다. 어떤 것은 드라이버 루틴의 지속 시간을 보고하고, 다른 것은 스케줄링 지연을 보고하며, 두 양은 같은 시스템에서 반대 방향으로 움직일 수 있다. 그중 하나를 그냥 DPC 지연이라고 부르는 대시보드는 보이는 것보다 적은 것을 알려 준다. 그래서 두 대시보드가 전혀 변하지 않은 시스템에 대해 서로 다른 말을 할 수 있다.

같은 주의가 하나의 분석 도구 안에서도 적용된다. 포함 지속 시간은 루틴을 진입에서 종료까지 따라가고, 배타 지속 시간은 그 루틴 자체가 실행되던 조각만 합산한다. 잘못된 열을 고르면 호출자가 범인이 된다.

로컬 드라이버 작업과 네트워크 지연도 융합하지 않은 채 상호 작용한다. 과도한 인터럽트 관련 활동은 시스템의 시간 민감 작업을 늦출 수 있고, 혼잡한 경로는 패킷을 늦출 수 있으며, 한 번의 눈에 보이는 중지 동안 둘 다 사실일 수 있다.

모든 관측을 하나의 시간 창에 담아라

추적은 증상이 들어 있는 구간을 읽을 때만 유용하다. 추적, 클라이언트 이벤트, 애플리케이션 실패를 타임스탬프와 함께 기록한 다음 세 가지에서 같은 초를 보라. 한 시간짜리 추적의 최댓값과 그날 오후 늦게 생긴 연결 끊김은 서로 무관한 두 사실이다.

wpr -start CPU -filemode
wpr -stop vpn-trace.etl
xperf -i vpn-trace.etl -a dpcisr -o dpc.txt

그런 다음 분석 도구에서 추적을 열고 전체 캡처가 아니라 그 시간 창 안의 지속 시간으로 정렬하라. CPU 분석 지침은 시간을 모듈과 함수에 귀속하는 DPC/ISR 지속 시간 보기를 설명한다.

터널에 실제로 무슨 일이 있었는지 확인하라 그곳에 있는 동안 확인하라. 애플리케이션 트래픽을 잠시 잃는 것이 클라이언트가 새 협상을 시작했다는 뜻은 아니며, 작은 프로브의 성공이 나머지 모두가 계속 작동했다는 증거는 아니다.

증거가 지목하는 구성 요소를 바꿔라

바쁜 모듈은 조사할 장소이지 판결이 아니다. 다른 구성 요소나 여러분이 만든 작업 부하가 일으킨 일을 하고 있을 수 있다. 모듈 이름, 장치, 드라이버 버전, 관측된 구간을 함께 유지하라. 바로 그 집합이 공급업체가 조치할 수 있는 근거다.

실험마다 변경을 하나로 두는 것이 결과에서 배우는 유일한 방법이다. 유선 비교는 범위를 좁히지만 동시에 무선 경로와 드라이버 활동을 바꾸므로, 증거가 아니라 단서로 다뤄라.

추적을 민감한 자료로 다뤄라. 프로세스 이름과 환경 세부 정보가 들어 있을 수 있으므로, 공개 첨부 파일이 아니라 지원되는 캡처 채널에 두어야 한다. 추적이 어떤 관측에 답하기 위한 것이었는지 밝혀라.