Nagu ka enamiku postituste, tekkis probleem jaotatud teenusega, nimetame seda teenust Elviniks. Seekord ei avastanud ma probleemi ise, vaid teatasid sellest kliendipoolsete kolleegide.

Üks päev ärkasin ma rahulolematust kirjast Elvini suurte latentsuste tõttu, mille me plaanisime peagi käivitada. Eeskätt koges klient 99. protsentiili latentsust umbes 50 ms, mis oli meie latentsuspiirist oluliselt kõrgem. See oli üllatav, kuna olin teenust põhjalikult testinud, eriti latentsuse osas, kuna see on sagedane kaebuste teema.

Enne, kui andsin Elvini testimiseks, tegin ma palju eksperimente 40 tuhande päringu sekundis (QPS) juures, kõik näitasid vähem kui 10 ms latentsust. Olin valmis väitma, et ei nõustu nende tulemustega. Kuid jälle vaadates kirja, pöörasin tähelepanu millelegi uuele: ma ei testinud tingimusi, millest nad rääkisid, nende QPS oli oluliselt madalam kui minu. Ma testisin 40k QPS korral, nad aga ainult 1k. Käivitasin veel ühe eksperimendi, seekord madalama QPS-iga, et neid rahuldada.

Kuna ma kirjutan sellest blogis - tõenäoliselt olete juba aru saanud: nende numbrid osutusid õigeks. Kontrollisin oma virtuaalset klienti ikka ja jälle, saades sama tulemuse: madal päringute arv suurendab mitte ainult latentsust, vaid ka päringute arvu, mis ületavad 10 ms. Teisisõnu, kui 40k QPS korral ületas umbes 50 päringut sekundis 50 ms, siis 1k QPS korral oli iga sekundi jooksul 100 päringut üle 50 ms. Paradoks!

Vähendame kahtlusaluste ringi

Kui seisame silmitsi latentsusprobleemiga jaotatud süsteemis, kus on palju komponente, tuleb kõigepealt koostada lühike kahtlusaluste nimekiri. Kaevame Elvini arhitektuuris veidi sügavamale:

Hea alguspunkt on loetelu tehtud sisendi-väljundi üleminekest (võrgukutsed / kettale otsimine jne). Proovime välja mõelda, kus on latentsus. Lisaks ilmselgele sisendi-väljundi suhtlemisele kliendiga, teeb Elvin veel ühe sammu: ta pöördub andmesalvestuse poole. Siiski töötab see salvestus Elvini kõrval ühes klastris, seega peaks selle latentsus olema väiksem kui kliendiga. Seega on kahtlusaluste nimekiri:

1. Võrgukutse kliendilt Elvinile.
2. Võrgukutse Elvinilt andmesalvesse.
3. Otsimine kettal andmesalvestuses.
4. Andmehoidla võrgu kõne Elvini suunas.
5. Võrgu kõne Elvini suunast kliendi suunas.

Proovime mõned punktid välja jätta.

Andmehoidla ei ole seotud.

Esimese asjana muutsin Elvini ping-ping serveriks, mis ei töötle päringuid. Päringu saades tagastab ta tühi vastus. Kui viivitus väheneb, on probleem Elvini või andmehoidla rakenduses — midagi ulmelist pole. Esimeses katses saame sellise graafiku:

Kuidas me näeme, ei täheldata ping-ping serveri kasutamisel mingeid parandusi. See tähendab, et andmehoidla ei suurenda viivitust, ja kahtlusaluste nimekiri väheneb poole võrra:

1. Võrgukutse kliendilt Elvinile.
2. Võrgu kõne Elvini suunast kliendi suunas.

Super! Nimekirja väheneb kiiresti. Ma arvasin, et olen peaaegu põhjuse välja selgitanud.

gRPC

Nüüd on õige aeg tutvustada teile uut mängijat: gRPC. See on Google'i avatud lähtekoodiga raamistik sisepoolsete suhtlemiseks. RPC. Kuigi gRPC on hästi optimeeritud ja laialdaselt kasutatud, kasutasin ma seda esmakordselt sellise mastaabisüsteemi puhul ning ootasin, et minu rakendus oleks, pehmelt öeldes, mitteoptimaalne.

Standardsete moodulite komplekti olemasolu gRPC tegelikult tõi meelde uue küsimuse: võib-olla on probleem viivituses minu rakenduses või ise gRPC ? Lisa nimekirja uus kahtlane:

1. Kliendi poolt kutsutud raamatukogu gRPC
2. Raamatukogu gRPC kliendis teostab raamatukogu võrgu kõne gRPC serveris
3. Raamatukogu gRPC viitab Elvinile (ping-pong serveri korral operatsiooni pole)

Et sa mõistaksid, milline on kood, on minu kliendi/Elvini rakendus üsna sarnane kliendi-serveri async näidistele..

Märkus: ülaltoodud nimekiri on veidi lihtsustatud, sest gRPC annab võimaluse kasutada oma (malle?) voogudemudelit, milles põimuvad täitmissteek gRPC ja kasutaja rakendus. Lihtsuse huvides jääme selle mudeli juurde.

Profiliseerimine parandab kõik.

Andmehoidlad välja jättes arvasin, et olen peaaegu valmis: „Nüüd on lihtne! Rakendame profiili ja uurime, kus viivitus tekib.“ Ma olen suur täpse profiilimise toetaja, sest CPU on väga kiired ega ole sageli kitsaskohaks. Enamik viivitusi toimub siis, kui protsessor peab töötlemise peatama, et teha midagi muud. Täpne CPU profiilimine ongi selleks, et see salvestab täpselt kõik konteksti vahetused ja annab arusaama, kus viivitused tekivad.

Otsisin nelja profiili: kõrge QPS (madal viivitus) ja ping-pongi server madala QPS-iga (suur viivitus), nii kliendi kui ka serveri poolel. Ja lihtsalt igaks juhuks võtsin ka protsessori profiili näidise. Profiilide võrdlemisel otsin tavaliselt ebanormaalset kutsungihunnikut. Näiteks halva jõudlusega, kõrge viivituse korral toimub konteksti vahetamine palju sagedamini (10 ja rohkem korda). Kuid minu puhul oli konteksti vahetuste arv praktiliselt sama. Mu kohutuseks polnud seal midagi olulist.

Lisa tõrkeotsing

Olin meeleheitel. Ma ei teadnud, milliseid tööriistu veel kasutada, ja minu järgmine plaan seisnes põhimõtteliselt katsete kordamises erinevate variatsioonidega, mitte probleemide täpses diagnoosimises.

Mis siis, kui

Alates esimesest hetkest häiris mind konkreetselt 50 ms viivitus. See on väga suur aeg. Otsustasin kärpida kooditükke, kuni suudan täpselt välja selgitada, milline osa selle vea põhjustab. Seejärel järgnes katse, mis töötas.

Kuid tavaliselt tundub tagantjärele, et kõik oli ilmne. Asetasin kliendi ühele masinale Elvini juurde — ja saatsin päringu localhost. Ja viivituse suurenemine kadus!

Midagi ei olnud otseselt korras võrguga.

Omandame võrguinseneri oskusi

Pean tunnistama: minu teadmised võrgu tehnoloogiatest on kohutavad, arvestades, et töötan nendega iga päev. Kuid võrk oli peamine kahtlusalune ja mul tuli õppida, kuidas seda tõrkeotsinguks kasutada.

Õnneks armastab internet õppida tahtega inimesi. Ping ja tracert kombinatsioon tundus olevat piisavalt hea algus võrgu transportimise probleemide tõrkeotsinguks.

Esiteks jooksin PsPing Elvini TCP-porti. Kasutasin vaikeseadeid — midagi erilist. Üle tuhande pingimisi ei ületanud ükski 10 ms, välja arvatud esimene soojenduseks. See on vastuolus 50 ms viivituse suurenemisega 99. protsendilis: seal peaks iga 100 päringu kohta olema umbes üks päring 50 ms viivitusega.

Seejärel proovisin tracert: ehk probleem on ühe sõlme juures marsruudi vahel Elvini ja kliendi vahel. Kuid jälgija tuli ka tühjade kätega tagasi.

Seeläbi ei olnud viivituse põhjus minu koodis, gRPC rakenduses ega võrgus. Olin juba hakanud muretsema, et ma ei saa seda kunagi aru.

Nüüd, millisel opsüsteemil me oleme

gRPC kasutatakse laialdaselt Linuxis, kuid Windowsis on see eksootiline. Otsustasin teha eksperimenti, mis õnnestus: lõin Linuxi virtuaalmasina, kompileerisin Elvini Linuxile ja juurutasin selle.

Ja siin on, mis juhtus: Linuxi ping-pong serveris ei olnud viivitusi nagu sarnasel Windowsi soliidil, kuigi andmeallikas ei olnud erinev. Selgub, et probleem on gRPC rakenduses Windowsile.

Neygle algoritm

Kogu selle aja arvasin, et mul puudub lipp gRPC. Nüüd sain aru, et tegelikult see on Windowsi gRPC lipu puudumine. Leidsin sisemise RPC teegi, mille suhtes olin kindel, et see töötab hästi kõikide installitud lipudega Winsock. Seejärel lisasin kõik need lipud gRPC-sse ja juurutasin Elvini Windowsis, parandatud ping-pong serveris Windowsile!

Peaaegu valmis: hakkasin eemaldama lisatud lippe ükshaaval, kuni regressioon naasis, nii et sain täpselt määrata selle põhjuse. See oli kurikuulus TCP_NODELAY, Neygle algoritmi lüliti.

Neygle algoritm üritab vähendada võrgu kaudu saadetavate pakkide arvu, viivitades sõnumite saatmist, kuni pakendi suurus ületab teatud baitide arvu. Kuigi see võib keskmisele kasutajale olla meeldiv, on see reaalajas serveritele hävitav, kuna opsüsteem viivitab teatud sõnumitega, põhjustades madala QPS-i korral viivitusi. Sellel gRPC lipp oli Linuxi TCP sokettide rakenduses paigaldatud, kuid mitte Windowsis. Ma tean, et parandasin.

Kokkuvõte

Suur viivitus madala QPS-i korral põhjustas opsüsteemi optimeerimine. Tagasi vaadates ei avastanud proffiilimine viivitust, kuna see toimus tuuma režiimis, mitte kasutajarežiimis. Ma ei tea, kas Neygle algoritmi on võimalik ETW konsoolidest näha, kuid see oleks huvitav.

Mis puudutab localhosti eksperimenti, siis see tõenäoliselt ei puudutanud tegelikku võrgu koodi ja Neygle algoritm ei käivitunud, seega kadusid viivitusega probleemid, kui klient pöördus Elvini poole localhosti kaudu.

Järgmine kord, kui näete viivituse suurenemist sekundite arvu vähenedes, peaks Neygle algoritm olema teie kahtlusaluste nimekirjas!

Allikas: habr.com