Nii nagu enamikus postitustes, tekkis probleem jaotatud teenusega, nimetame seda teenust Elviniks. Seekord ma ei avastanud probleemi iseseisvalt, mulle rääkisid sellest klienditugi.

Ühel hommikul ärkasin ma rahulolematust kirjast, mille põhjus oli suured latentsused Elvini juures, mida plaanisime peagi käivitada. Eelkõige koges klient 99. protsentiili latentsust umbes 50 ms, mis oli meie latentsuse eelarvest oluliselt kõrgem. See oli üllatav, kuna olin teenust põhjalikult testinud, eriti latentsuse osas, mis on sagedane kaebuste teema.

Enne kui andsin Elvini testimiseks, tegin palju katseid 40 000 päringut sekundis (QPS) juures, tulemused näitasid kõik latentsust alla 10 ms. Olin valmis esitama väite, et ma ei nõustu nende tulemustega. Kuid vaadates uuesti kirja, märkasin midagi uut: ma ei olnud testi teinud nende mainitud tingimustes, nende QPS oli oluliselt madalam kui minu. Olin testinud 40k QPS juures, samas kui nemad vaid 1k juures. Käivitasin veel ühe katse, seekord madalama QPS-iga, lihtsalt et neid rahuldada.

Kuna ma kirjutan sellest blogis – ilmselt olete juba aru saanud: nende numbrid osutusid õigeks. Olen oma virtuaalset klienti korduvalt kontrollinud, tulemuseks on ikka sama: madal päringute arv mitte ainult ei suurenda viivitust, vaid ka päringute arvu, mille viivitus ületab 10 ms. Teisisõnu, kui 40k QPS juures ületas umbes 50 päringut sekundis 50 ms, siis 1k QPS puhul oli iga sekund 100 päringut, mis ületasid 50 ms. Paradoks!

Kitsendame otsinguulatust

Viivituse probleemiga kokku puutudes kompleksse süsteemi mitme komponendiga tuleb kõigepealt koostada lühike kahtlusaluste nimekiri. Kaevame veidi sügavamale Elvini arhitektuuri:

Hea lähtepunkt on teostatud sisendi-väljundi üleminekute (võrgukutsed/diskid ja jne) nimekiri. Proovime välja selgitada, kus on viivitus. Lisaks ilmselgele sisendi-väljundile kliendiga, teeb Elvin veel ühe sammu: ta pöördub andmestikku. Kuid see andmestik töötab koos Elviniga ühes klastris, seega peab sealne viivitus olema väiksem kui kliendiga. Seega, kahtlusaluste nimekiri:

1. Kliendi võrgu kutsumine Elvinile.
2. Elvin'i andmehoidla võrgu kõne.
3. Andmehoidla kettalt otsing.
4. Andmehoidla kõne Elvin'ist.
5. Elvin'i ja kliendi vahel võrgu kõne.

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

Andmehoidla ei mängi rolli.

Esimesena muutsin Elvin'i ping-ping serveriks, mis ei töötle päringuid. Päringu saades tagastab ta tühja vastuse. Kui latentsus väheneb, siis on viga kas Elvin'is või andmehoidlas — midagi ebatavalist. Esimeses eksperimendis saime sellise graafiku:

Nagu näeme, ei ole ping-ping serveri kasutamisel mingeid parandusi. See tähendab, et andmehoidla ei suurenda latentsust ja kahtlusaluste nimekiri väheneb poole võrra:

1. Kliendi võrgu kutsumine Elvinile.
2. Elvin'i ja kliendi vahel võrgu kõne.

Suurepärane! Nimekiri väheneb kiiresti. 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 teek sisemiseks protsessidevaheliseks suhtlemiseks. RPC. Kuigi gRPC on hästi optimeeritud ja laialdaselt kasutatav, kasutasin ma seda esmakordselt sellise suurusega süsteemis ja ootasin, et minu rakendus oleks vähem optimeeritud — õrnalt öeldes.

Olemasolu gRPC steigis tekitas uue küsimuse: võib-olla on see minu rakendus või gRPC tekitab probleemi viivitusega? Lisame uue kahtlusaluse nimekirja:

1. Kliendi poolt kutsutakse esile raamatukogu gRPC
2. Raamatukogu gRPC võrgukõne teostamiseks raamatukogu kliendis gRPC serveris
3. Raamatukogu gRPC suunab Elvinile (ping-pongi serveri juhtumitel ei toimu operatsioone)

Et mõista, milline näeb välja kood, ei erine minu kliendi/Elvini rakendus oluliselt kliendi-serveri asünkroonsete näidete.

Märkus: ülaltoodud nimekiri on veidi lihtsustatud, kuna gRPC see võimaldab kasutada oma (mustriga?) voolumudelit, kus kassa täitmise gRPC ja kasutaja rakendus on põimunud. Lihtsuse huvides jääme selle mudeli juurde.

Profiliseerimine parandab kõik

Andmesalvestuste eemaldamisel mõtlesin, et peaaegu lõpetasin: „Nüüd on lihtne! Rakendame profiili ja vaatame, kus viivitus tekib.” Mina olen täpse profiliseerimise suur austaja, sest kuna CPU on väga kiire ning tavaliselt ei ole see kitsaskohaks. Enamik viivitustest tekib siis, kui protsessor peab töötamise peatama, et midagi muud teha. Täpne CPU profiilimine on selleks, et täpselt salvestada kõik kontekstivahetused ja aru saada, kus viivitused tekivad.

Võtsin neli profiili: kõrgendatud QPS (väike viivitus) ja ping-pong server madala QPS-iga (suur viivitus), nii kliendi kui ka serveri küljelt. Ja igaks juhuks võtsin ka protsessori profiili. Profiilide võrdlemisel otsin tavaliselt anomaalset funktsioonide virna. Näiteks kõrge viivitusega nõrgas küljel toimub palju rohkem kontekstivahetusi (10 ja rohkem korda). Kuid minu puhul oli kontekstivahetuste arv praktiliselt sama. Minu õuduseks ei leidnud ma sealt midagi olulist.

Täiendav tõrkeotsing

Olin meeleheites. Ma ei teadnud, milliseid tööriistu veel kasutada, ja minu järgmine plaan seisnes peamiselt katsete kordamises erinevate variantide abil, mitte probleemide selges diagnoosimises.

Mis siis, kui

Algusest peale muretsesin 50 ms latentsuse pärast. See on väga pikk aeg. Otsustasin, et hakkan koodist osi välja lõikama, kuni suudan täpselt välja selgitada, milline osa tekitab vea. Järgmine eksperiment töötas.

Kuidas tavaliselt, tagantjärele tundub, et kõik oli ilmne. Asetasin kliendi ühte masinasse Elviniga — ja saatsin päringu localhost. Latentsus suurenes ja kadus!

Midagi polnud võrku rahuldav.

Õppida võrguinseneri oskusi

Pean tunnistama: minu teadmised võrgutehnoloogiatest on kohutavad, arvestades, et töötan nendega iga päev. Kuid võrk oli peamine kahtlusalune ja ma pidin õppima, kuidas seda tõrkeotsida.

Õnneks armastab internet neid, kes tahavad õppida. Ping ja tracert tundusid olevat piisavalt hea algus võrgu transportimise probleemide tõrkeotsimiseks.

Esiteks käivitasin PsPing TCP-pordile Alvinile. Kasutasin vaikimisi seadeid — mitte midagi erilist. Üle tuhande pingi hulgas ei ületanud ükski 10 ms, välja arvatud esimene soojenduseks. See on vastuolus 99. protsendi puhul märgatud viivituse suurenemisega 50 ms: seal peaksime iga 100 päringu kohta nägema umbes ühte päringut, mille viivitus on 50 ms.

Seejärel proovisin tracert: võib-olla on probleem mõnes sõlmes, mis asub marsruudi vahel Alvinist kliendini. Kuid jälgimise tulemused ei toonud samuti midagi käega katsuda.

Nii et viivituse põhjuseks ei olnud minu kood, gRPC teostus ega võrk. Olen juba hakanud muretsema, et ei saa seda kunagi selgeks.

Nüüd, millisel operatsioonisüsteemil me oleme

gRPC on Linuxis laialdaselt kasutatav, kuid Windowsis on see eksootika. Otsustasin läbi viia eksperimenti, mis osutus edukaks: lõin Linuxi virtuaalmasina, kompileerisin Alvin Linuxile ja seadistasin selle.

Ja siin on, mis välja tuli: Linuxi ping-pong serveris ei olnud viivitusi nagu sarnasel Windowsi sõlmel, kuigi andmeallikas ei olnud erinev. Selgub, et probleem on gRPC teostuses Windowsis.

Nagle'i algoritm

Mitu korda arvasin, et mul on lipust puudu gRPC. Nüüd sain aru, et see on tegelikult tugevuses gRPC Windowsi lipseb. Leidsin sisemise RPC teegi, mille uskusin töötavat kõikide paigaldatud lipudega. Winsock. Siis lisasin kõik need lipud gRPC-sse ja juurutasin Elvini Windowsile, parandatud ping-pongi serveris Windowsis!

Peaaegu valmis: hakkasin eemaldama lisatud lippe üksainus, kuni regressioon tagasi tuli, et saaksin täpselt selle põhjuse kindlaks teha. See oli tuntud TCP_NODELAY, Nagle'i algoritmi lüliti.

Nagle'i algoritm püüab vähendada võrgus saadetud pakettide arvu, viies sõnumite edastamise viivituse kuni paketi suurus ületab teatud baitide arvu. Kuigi see võib olla meeldiv tavalise kasutaja jaoks, on see hävitav reaalajas serverite jaoks, kuna opsüsteem viivitab teatud sõnumite edastamisega, põhjustades viivitusi madala QPS-i korral. gRPC See lipp oli seadistatud Linuxi teostuses TCP socketite jaoks, kuid mitte Windowsis. Ma selle parandasin..

Kokkuvõte

Suur viivitus madala QPS-i tõttu oli tingitud opsüsteemi optimeerimisest. Tagasi vaadates ei leidnud profilter viivitust, kuna see viidi läbi tuumikurežiimis, mitte kasutajarežiimis.. Ma ei tea, kas Neiglandi algoritmi on võimalik jälgida ETW kaudu, kuid see oleks huvitav.

Mis puutub localhosti eksperimenti, siis see ei hõlmanud tõenäoliselt tegelikku võrguedastust ning Neiglandi algoritm ei käivitatud, mistõttu viivitusprobleemid kadusid, kui klient pöördus Elvini poole localhosti kaudu.

Järgmine kord, kui märkate viivituse suurenemist, kui sekundis tehtavate päringute arv väheneb, peaks Neiglandi algoritm olema teie kahtlusaluste nimekirjas!

Allikas: habr.com