Augsta DPC latentums nenozīmē lēnu VPN ceļu

Audio defekts un VPN pauze iekrīt tajās pašās desmit sekundēs, un kāda utilītprogramma ziņo par augstu skaitli ar apzīmējumu DPC latentums. Kārdinājums ir secināt, ka draiveris palēnina tuneli vai ka tunelis noslogo draiveri. Neviens no šiem secinājumiem neizriet no šī skaitļa.

Šeit darbojas trīs mērījumi, un tiem nav vienas kopīgas robežas.

Trīs skaitļi, trīs robežas

Atlikts procedūras izsaukums ir darbs, ko draiveris atliek no sava pārtraukumu apstrādātāja, un laiks, kas pavadīts šajās rutīnās, ir procesoram lokāls mērījums, kas attiecināts uz moduļiem un funkcijām. Atbalss ceļojums turp un atpakaļ ir laika novērojums ligzdā, ko rada tīkla steks un attāls atbildētājs. Atvienošanās notikums ir stāvokļa pāreja, ko fiksē klients. Katrs atbild uz jautājumu, uz kuru pārējie nevar, un vienādas vienības nepadara tos savstarpēji aizstājamus.

Noderīga disciplīna ir nosaukt robežu pirms vērtības nolasīšanas. Ierakstiet vienību un robežu blakus. Ja rīks ziņo par milisekundēm, jautājiet, kādu milisekundes: laiks rutīnas iekšienē, gaidīšanas laiks līdz izpildei vai laiks līdz atbildes ierašanās brīdim.

Augsts skaitlis vienā kategorijā ir pavediens, nekad diagnoze.

Izlasiet definīciju aiz virsraksta

Utilītprogrammas atšķiras ar to, ko tās sauc par latentumu. Dažas ziņo par draivera rutīnu ilgumu, citas par plānošanas aizkavi, un šie divi lielumi tajā pašā mašīnā var kustēties pretējos virzienos. Informācijas panelis, kas vienu no tiem sauc vienkārši par DPC latentumu, ir pastāstījis mazāk, nekā šķiet. Tāpēc divi paneļi var nesaskanēt par mašīnu, kas nemaz nav mainījusies.

Tāda pati piesardzība attiecas arī uz vienu analīzes rīku. Ietverošais ilgums seko rutīnai no ieejas līdz izejai, bet izslēdzošais ilgums summē tikai tos fragmentus, kuros pati rutīna izpildījās. Nepareizas kolonnas izvēle pārvērš izsaucēju par vainīgo.

Vietējais draivera darbs un tīkla aizkave arī mijiedarbojas, nesaplūstot. Pārmērīga ar pārtraukumiem saistīta aktivitāte var aizkavēt laikjutīgu darbu mašīnā, un pārslogots ceļš var aizkavēt paketes, un abi var būt patiesi vienas redzamas pauzes laikā.

Ievietojiet katru novērojumu vienā logā

Izsekošana ir noderīga tikai tad, ja jūs lasāt intervālu, kurā ir simptoms. Ierakstiet izsekošanu, klienta notikumu un lietotnes kļūmi ar laika zīmogiem, pēc tam apskatiet tās pašas sekundes visos trijos. Stundas izsekošanas maksimums un vēlāk pēcpusdienā notikusi atvienošanās ir divi nesaistīti fakti.

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

Pēc tam atveriet izsekošanu analīzes rīkā un kārtojiet pēc ilguma šajā logā, nevis pēc visa ieraksta. procesora analīzes vadlīnijas apraksta DPC/ISR ilguma skatu, kas laiku attiecina uz moduļiem un funkcijām.

Apstipriniet, kas tunelim patiešām notika, kamēr esat tur. Īslaicīgs lietotnes trafika zudums nenozīmē, ka klients sāka jaunas pārrunas, un mazas pārbaudes panākums nepierāda, ka viss pārējais turpināja darboties.

Nomainiet komponentu, uz kuru norāda pierādījumi

Aizņemts modulis ir izmeklēšanas vieta, nevis spriedums. Tas var veikt darbu, ko izraisījis cits komponents vai jūsu radītā slodze. Turiet kopā moduļa nosaukumu, ierīci, draivera versiju un novēroto intervālu, jo tieši šī kopa ir tas, uz ko piegādātājs var reaģēt.

Viena izmaiņa vienā eksperimentā ir vienīgais veids, kā mācīties no rezultāta. Vadu salīdzinājums sašaurina apjomu, bet tas vienlaikus maina radioceļu un draivera aktivitāti, tāpēc uzskatiet to par pavedienu, nevis pierādījumu.

Uzskatiet izsekošanu par sensitīvu. Tajā var būt procesu nosaukumi un vides informācija, tāpēc tās vieta ir atbalstītajā ierakstīšanas kanālā, nevis publiskā pielikumā. Pasakiet, uz kuru novērojumu izsekošanai bija jāatbild.