ProHoster > Blogs > Administrācija > Dažreiz vairāk ir mazāk. Samazinot slodzi, palielinās latentums

Dažreiz vairāk ir mazāk. Samazinot slodzi, palielinās latentums

Kā iekŔā lielākā daļa ziņu, ir problēma ar izplatÄ«tu pakalpojumu, sauksim Å”o pakalpojumu par Alvinu. Å oreiz es pats neatklāju problēmu, mani informēja puiÅ”i no klienta puses.

Kādu dienu es pamodos no neapmierināta e-pasta saistÄ«bā ar ilgu kavÄ“Å”anos ar Alvinu, kuru plānojām palaist tuvākajā nākotnē. Konkrēti, klientam bija 99. procentiles latentums aptuveni 50 ms, kas ir krietni virs mÅ«su latentuma budžeta. Tas bija pārsteidzoÅ”i, jo es plaÅ”i pārbaudÄ«ju pakalpojumu, jo Ä«paÅ”i attiecÄ«bā uz latentumu, kas ir izplatÄ«ta sÅ«dzÄ«ba.

Pirms Alvina testÄ“Å”anas es veicu daudz eksperimentu ar 40 10 vaicājumu sekundē (QPS), un visi uzrādÄ«ja latentumu, kas mazāks par 40 ms. Es biju gatavs paziņot, ka nepiekrÄ«tu viņu rezultātiem. Bet vēlreiz aplÅ«kojot vēstuli, es pamanÄ«ju kaut ko jaunu: es nebiju precÄ«zi pārbaudÄ«jis viņu minētos apstākļus, viņu QPS bija daudz zemāks nekā manējais. Es testēju ar 1k QPS, bet viņi tikai ar XNUMXk. Es veicu vēl vienu eksperimentu, Å”oreiz ar zemāku QPS, lai viņus nomierinātu.

Tā kā es rakstu par Å”o emuāru, jÅ«s droÅ”i vien jau esat sapratuÅ”i, ka viņu skaitļi bija pareizi. Es atkal un atkal pārbaudÄ«ju savu virtuālo klientu ar vienu un to paÅ”u rezultātu: mazs pieprasÄ«jumu skaits ne tikai palielina latentumu, bet arÄ« palielina pieprasÄ«jumu skaitu, kuru latentums pārsniedz 10 ms. Citiem vārdiem sakot, ja pie 40k QPS aptuveni 50 pieprasÄ«jumi sekundē pārsniedza 50 ms, tad pie 1k QPS bija 100 pieprasÄ«jumi virs 50 ms katrā sekundē. Paradokss!

Dažreiz vairāk ir mazāk. Samazinot slodzi, palielinās latentums

MeklÄ“Å”anas saÅ”aurināŔanās

Saskaroties ar latentuma problēmu izplatītā sistēmā ar daudziem komponentiem, pirmais solis ir izveidot īsu aizdomās turamo sarakstu. Iedziļināsimies Alvina arhitektūrā:

Dažreiz vairāk ir mazāk. Samazinot slodzi, palielinās latentums

Labs sākumpunkts ir pabeigto I/O pāreju saraksts (tÄ«kla zvani/diska meklÄ“Å”ana utt.). Mēģināsim noskaidrot, kur ir kavÄ“Å”anās. Papildus acÄ«mredzamajai ievadei/izvadei ar klientu Alvins veic papildu soli: viņŔ piekļūst datu krātuvei. Tomēr Ŕī krātuve darbojas tajā paŔā klasterÄ« kā Alvin, tāpēc latentumam tajā jābÅ«t mazākam nekā klientam. Tātad aizdomās turamo saraksts:

  1. TÄ«kla zvans no klienta Alvinam.
  2. Tīkla zvans no Alvin uz datu krātuvi.
  3. Meklēt diskā datu krātuvē.
  4. TÄ«kla zvans no datu noliktavas uz Alvinu.
  5. TÄ«kla zvans no Alvin klientam.

Mēģināsim izsvītrot dažus punktus.

Datu glabāŔanai ar to nav nekāda sakara

Pirmā lieta, ko es izdarÄ«ju, bija Alvin pārveidot par ping-ping serveri, kas neapstrādā pieprasÄ«jumus. Kad tas saņem pieprasÄ«jumu, tas atgriež tukÅ”u atbildi. Ja latentums samazinās, Alvin vai datu noliktavas ievieÅ”anas kļūda nav nekas nedzirdēts. Pirmajā eksperimentā mēs iegÅ«stam Ŕādu grafiku:

Dažreiz vairāk ir mazāk. Samazinot slodzi, palielinās latentums

Kā redzat, ping-ping serveri nav uzlabojumu. Tas nozīmē, ka datu noliktava nepalielina latentumu, un aizdomās turamo saraksts tiek samazināts uz pusi:

  1. TÄ«kla zvans no klienta Alvinam.
  2. TÄ«kla zvans no Alvin klientam.

Lieliski! Saraksts strauji sarūk. Man likās, ka esmu gandrīz sapratis iemeslu.

grRPC

Tagad ir pienācis laiks iepazÄ«stināt jÅ«s ar jaunu spēlētāju: grRPC. Å Ä« ir Google atvērtā pirmkoda bibliotēka saziņai procesa laikā RPC. Kaut gan gRPC labi optimizēta un plaÅ”i izmantota, Ŕī bija mana pirmā reize, kad to izmantoju Ŕāda izmēra sistēmā, un es gaidÄ«ju, ka mana ievieÅ”ana bÅ«s neoptimāla - lai neteiktu vairāk.

pieejamÄ«ba gRPC kaudzē radÄ«ja jaunu jautājumu: varbÅ«t tā ir mana Ä«stenoÅ”ana vai es gRPC rada latentuma problēmu? Jauna aizdomās turamā pievienoÅ”ana sarakstam:

  1. Klients zvana uz bibliotēku gRPC
  2. Bibliotēka gRPC veic tīkla zvanu uz klienta bibliotēku gRPC serverī
  3. Bibliotēka gRPC sazinās ar Alvinu (ping-pong servera gadījumā nedarbojas)

Lai sniegtu jums priekÅ”statu par to, kā izskatās kods, mana klienta/Alvina ievieÅ”ana daudz neatŔķiras no klienta-servera ievieÅ”anas. asinhronie piemēri.

PiezÄ«me: iepriekÅ” minētais saraksts ir nedaudz vienkārÅ”ots, jo gRPC dod iespēju izmantot savu (veidnes?) vÄ«tņoÅ”anas modeli, kurā savijas izpildes kaudze gRPC un lietotāja ievieÅ”ana. VienkārŔības labad mēs paliksim pie Ŕī modeļa.

ProfilēŔana visu izlabos

IzsvÄ«trojis datu krātuves, es domāju, ka esmu gandrÄ«z pabeidzis: ā€œTagad tas ir vienkārÅ”i! Pielietosim profilu un noskaidrosim, kur notiek kavÄ“Å”anās. es liels precÄ«zas profilÄ“Å”anas cienÄ«tājs, jo CPU ir ļoti ātri un visbiežāk tie nav saÅ”aurinājums. Lielākā daļa aizkaves rodas, ja procesoram jāpārtrauc apstrāde, lai veiktu kaut ko citu. PrecÄ«za CPU profilÄ“Å”ana to dara: tā precÄ«zi ieraksta visu konteksta slēdži un skaidri norāda, kur notiek kavÄ“Å”anās.

Es izvēlējos četrus profilus: ar augstu QPS (zemu latentumu) un ar galda tenisa serveri ar zemu QPS (augstu latentumu) gan klienta, gan servera pusē. Un katram gadÄ«jumam paņēmu arÄ« procesora profila paraugu. SalÄ«dzinot profilus, es parasti meklēju anomālu zvanu steku. Piemēram, sliktajā pusē ar lielu latentumu ir daudz vairāk konteksta slēdžu (10 reizes vai vairāk). Bet manā gadÄ«jumā konteksta slēdžu skaits bija gandrÄ«z vienāds. Man par Å”ausmām tur nebija nekā nozÄ«mÄ«ga.

Papildu atkļūdoŔana

Es biju izmisusi. Es nezināju, kādus citus rīkus es varētu izmantot, un mans nākamais plāns būtībā bija atkārtot eksperimentus ar dažādām variācijām, nevis skaidri diagnosticēt problēmu.

Ko darīt, ja

Jau no paÅ”a sākuma mani uztrauca konkrētais 50 ms latentums. Å is ir ļoti liels laiks. Es nolēmu, ka es izgriezÄ«Å”u gabalus no koda, lÄ«dz varÄ“Å”u precÄ«zi noskaidrot, kura daļa izraisÄ«ja Å”o kļūdu. Tad sekoja eksperiments, kas darbojās.

Kā jau ierasts, vēlāk Ŕķiet, ka viss bija paÅ”saprotami. Es ievietoju klientu tajā paŔā maŔīnā, kur Alvins - un nosÅ«tÄ«ju pieprasÄ«jumu localhost. Un latentuma pieaugums ir pagājis!

Dažreiz vairāk ir mazāk. Samazinot slodzi, palielinās latentums

Kaut kas nebija kārtībā ar tīklu.

Apgūst tīkla inženiera prasmes

JāatzÄ«st: manas zināŔanas par tÄ«kla tehnoloÄ£ijām ir Å”ausmÄ«gas, Ä«paÅ”i ņemot vērā to, ka ar tām strādāju ikdienā. Taču tÄ«kls bija galvenais aizdomās turamais, un man bija jāiemācās to atkļūdot.

Par laimi, internets mÄ«l tos, kas vēlas mācÄ«ties. Ping un tracert kombinācija Ŕķita pietiekami labs sākums tÄ«kla transporta problēmu atkļūdoÅ”anai.

Pirmkārt, es palaidu PsPing uz Alvina TCP portu. Es izmantoju noklusējuma iestatÄ«jumus - nekas Ä«paÅ”s. No vairāk nekā tÅ«kstoÅ” ping neviens nepārsniedza 10 ms, izņemot pirmo iesildÄ«Å”anai. Tas ir pretrunā ar novēroto latentuma palielināŔanos par 50 ms pie 99. procentiles: tur uz katriem 100 pieprasÄ«jumiem mums vajadzēja redzēt apmēram vienu pieprasÄ«jumu ar latentumu 50 ms.

Tad es mēģināju tracert: Var bÅ«t problēma vienā no mezgliem marÅ”rutā starp Alvinu un klientu. Taču arÄ« izsekotājs atgriezās tukŔām rokām.

Tātad aizkavi izraisīja nevis mans kods, gRPC ievieŔana vai tīkls. Es sāku uztraukties, ka es to nekad nesapratīŔu.

Tagad kādu OS mēs izmantojam

gRPC plaÅ”i izmantots operētājsistēmā Linux, bet eksotisks operētājsistēmā Windows. Es nolēmu izmēģināt eksperimentu, kas darbojās: izveidoju Linux virtuālo maŔīnu, kompilēju Alvin for Linux un izvietoju to.

Dažreiz vairāk ir mazāk. Samazinot slodzi, palielinās latentums

Un notika Ŕādi: Linux galda tenisa serverim nebija tādas paÅ”as aizkaves kā lÄ«dzÄ«gam Windows resursdatoram, lai gan datu avots neatŔķīrās. Izrādās, ka problēma ir gRPC ievieÅ”anā operētājsistēmai Windows.

Nagles algoritms

Visu Å”o laiku es domāju, ka man trÅ«kst karoga gRPC. Tagad es saprotu, kas tas Ä«sti ir gRPC TrÅ«kst Windows karoga. Es atradu iekŔējo RPC bibliotēku, par kuru biju pārliecināts, ka tā labi darbosies visiem karodziņu komplektiem Winsock. Pēc tam es pievienoju visus Å”os karogus grRPC un izvietoju Alvin operētājsistēmā Windows, labotā Windows galda tenisa serverÄ«!

Dažreiz vairāk ir mazāk. Samazinot slodzi, palielinās latentums

Gandrīz Gatavs: es sāku noņemt pievienotos karogus pa vienam, līdz regresija atgriezās, lai varētu precīzi noteikt cēloni. Tas bija bēdīgi slavens TCP_NODELAY, Nagles algoritma slēdzis.

Nagles algoritms mēģina samazināt tÄ«klā nosÅ«tÄ«to pakeÅ”u skaitu, aizkavējot ziņojumu pārraidi, lÄ«dz pakeÅ”u lielums pārsniedz noteiktu baitu skaitu. Lai gan tas var bÅ«t patÄ«kami parastam lietotājam, tas ir destruktÄ«vs reāllaika serveriem, jo ā€‹ā€‹OS aizkavēs dažus ziņojumus, izraisot zema QPS aizkavÄ“Å”anos. U gRPC Å”is karodziņŔ tika iestatÄ«ts Linux ievieÅ”anā TCP ligzdām, bet ne sistēmā Windows. Es esmu Å”is labots.

Secinājums

Lielāku latentumu pie zema QPS izraisÄ«ja OS optimizācija. RetrospektÄ«vi, profilÄ“Å”ana nekonstatēja latentumu, jo tā tika veikta kodola režīmā, nevis iekŔā lietotāja režīms. Es nezinu, vai Nagle algoritmu var novērot, izmantojot ETW tverÅ”anu, bet tas bÅ«tu interesanti.

Kas attiecas uz localhost eksperimentu, tas, iespējams, nepieskārās faktiskajam tīkla kodam un Nagle algoritms nedarbojās, tāpēc latentuma problēmas pazuda, kad klients sasniedza Alvin, izmantojot localhost.

Nākamreiz, kad redzēsiet latentuma pieaugumu, jo samazinās pieprasījumu skaits sekundē, Nagle algoritmam vajadzētu būt jūsu aizdomās turamo sarakstā!

Avots: www.habr.com

Pievieno komentāru