Eins og í flestar færslur, það er vandamál með dreifða þjónustu, við skulum kalla þessa þjónustu Alvin. Í þetta skiptið uppgötvaði ég ekki vandamálið sjálfur, krakkarnir frá viðskiptavininum sögðu mér það.

Einn daginn vaknaði ég við óánægðan tölvupóst vegna mikilla tafa með Alvin, sem við ætluðum að setja á markað á næstunni. Nánar tiltekið upplifði viðskiptavinurinn 99. hundraðshluta leynd á svæðinu 50 ms, vel yfir leynd kostnaðarhámarki okkar. Þetta kom á óvart þar sem ég prófaði þjónustuna mikið, sérstaklega varðandi leynd, sem er algeng kvörtun.

Áður en ég setti Alvin í próf, gerði ég margar tilraunir með 40 fyrirspurnir á sekúndu (QPS), sem allar sýndu leynd sem er innan við 10ms. Ég var tilbúinn að lýsa því yfir að ég væri ekki sammála niðurstöðum þeirra. En þegar ég horfði aftur á bréfið tók ég eftir einhverju nýju: Ég hafði ekki nákvæmlega prófað aðstæðurnar sem þeir nefndu, QPS þeirra var miklu lægra en mitt. Ég prófaði á 40k QPS, en þeir voru aðeins á 1k. Ég gerði aðra tilraun, að þessu sinni með lægri QPS, bara til að friðþægja þá.

Þar sem ég er að blogga um þetta hefur þú sennilega þegar áttað þig á því að tölurnar þeirra voru réttar. Ég prófaði sýndarbiðlarann minn aftur og aftur, með sömu niðurstöðu: lítill fjöldi beiðna eykur ekki aðeins leynd heldur eykur fjölda beiðna með töf sem er meira en 10 ms. Með öðrum orðum, ef við 40k QPS fóru um 50 beiðnir á sekúndu yfir 50 ms, þá voru við 1k QPS 100 beiðnir yfir 50 ms á sekúndu. Þversögn!

Að þrengja leitina

Þegar þú stendur frammi fyrir leynd vandamáli í dreifðu kerfi með mörgum íhlutum, er fyrsta skrefið að búa til stuttan lista yfir grunaða. Við skulum kafa aðeins dýpra í arkitektúr Alvins:

Góður upphafspunktur er listi yfir lokið I/O umskipti (netsímtöl/diskaleit o.s.frv.). Við skulum reyna að finna út hvar seinkunin er. Fyrir utan augljósa I/O með viðskiptavininum, tekur Alvin aukaskref: hann opnar gagnageymsluna. Hins vegar starfar þessi geymsla í sama klasa og Alvin, þannig að leynd þar ætti að vera minni en hjá viðskiptavininum. Svo, listinn yfir grunaða:

Netsímtal frá viðskiptavini til Alvin.
Netsímtal frá Alvin í gagnageymsluna.
Leitaðu á diski í gagnageymslunni.
Símtal frá gagnageymslunni til Alvins.
Netsímtal frá Alvin til viðskiptavinar.

Við skulum reyna að strika yfir nokkur atriði.

Gagnageymsla hefur ekkert með það að gera

Það fyrsta sem ég gerði var að breyta Alvin í ping-ping netþjón sem vinnur ekki úr beiðnum. Þegar það fær beiðni skilar það tómu svari. Ef leynd minnkar, þá er galli í Alvin eða gagnavöruhúsum útfærslu ekkert óheyrður. Í fyrstu tilrauninni fáum við eftirfarandi línurit:

Eins og þú sérð er engin framför þegar þú notar ping-ping netþjóninn. Þetta þýðir að gagnavöruhúsið eykur ekki leynd og listinn yfir grunaða er skorinn niður um helming:

Netsímtal frá viðskiptavini til Alvin.
Netsímtal frá Alvin til viðskiptavinar.

Frábært! Listinn minnkar hratt. Ég hélt að ég hefði næstum áttað mig á ástæðunni.

gRPC

Nú er kominn tími til að kynna þér nýjan leikmann: gRPC. Þetta er opið bókasafn frá Google fyrir samskipti í ferli CPR. Þó gRPC vel bjartsýni og mikið notaður, þetta var í fyrsta skipti sem ég nota það á kerfi af þessari stærð og ég bjóst við að útfærslan mín yrði ekki ákjósanleg - vægast sagt.

framboð gRPC í stafla gaf tilefni til nýrrar spurningar: kannski er það útfærslan mín eða ég gRPC veldur leynd vandamál? Bætir nýjum grunuðum á listann:

Viðskiptavinurinn hringir í bókasafnið gRPC
Bókasafnið gRPC hringir net í bókasafnið á biðlaranum gRPC á server
Bókasafnið gRPC tengiliðir Alvin (engin aðgerð ef um borðtennisþjón er að ræða)

Til að gefa þér hugmynd um hvernig kóðinn lítur út, þá er viðskiptavinur/Alvin útfærsla mín ekki mikið frábrugðin þeim sem eru á biðlaraþjóninum ósamstillt dæmi.

Athugið: Listinn hér að ofan er aðeins einfaldari vegna þess gRPC gerir þér kleift að nota þitt eigið (sniðmát?) þráðarmódel, þar sem framkvæmdarstafla er samtvinnað gRPC og innleiðingu notenda. Til einföldunar munum við halda okkur við þetta líkan.

Profiling mun laga allt

Eftir að hafa strikað yfir gagnageymslurnar hélt ég að ég væri næstum búinn: „Nú er það auðvelt! Við skulum nota prófílinn og komast að því hvar seinkunin á sér stað. ég mikill aðdáandi nákvæmni prófílgreiningar, vegna þess að örgjörvar eru mjög hraðir og eru oftast ekki flöskuhálsinn. Flestar tafir eiga sér stað þegar örgjörvinn verður að hætta að vinna til að gera eitthvað annað. Nákvæm CPU-snið gerir einmitt það: hún skráir allt nákvæmlega samhengisrofa og gerir það ljóst hvar tafir verða.

Ég tók fjögur snið: með háu QPS (lág leynd) og með borðtennisþjóni með lágu QPS (hári leynd), bæði á biðlarahlið og á þjóninum. Og svona til öryggis tók ég líka sýnishorn af örgjörvasniði. Þegar ég ber saman prófíla leita ég venjulega að afbrigðilegum símtölum. Til dæmis, á slæmu hliðinni með mikla leynd eru miklu fleiri samhengisrofar (10 sinnum eða oftar). En í mínu tilfelli var fjöldi samhengisrofa næstum sá sami. Mér til skelfingar var ekkert merkilegt þarna.

Viðbótar villuleit

Ég var örvæntingarfullur. Ég vissi ekki hvaða önnur tæki ég gæti notað og næsta áætlun mín var í rauninni að endurtaka tilraunirnar með mismunandi afbrigðum frekar en að greina vandann greinilega.

Hvað ef

Frá upphafi hafði ég áhyggjur af tiltekinni 50ms leynd. Þetta er mjög stór tími. Ég ákvað að ég myndi skera klumpur úr kóðanum þar til ég gæti fundið út nákvæmlega hvaða hluti var að valda þessari villu. Svo kom tilraun sem virkaði.

Eins og venjulega, eftir á að hyggja, virðist sem allt hafi verið augljóst. Ég setti viðskiptavininn á sömu vél og Alvin - og sendi beiðni til localhost. Og aukningin á leynd er horfin!

Eitthvað var að netkerfinu.

Að læra netverkfræðingahæfileika

Ég verð að viðurkenna: þekking mín á nettækni er hræðileg, sérstaklega í ljósi þess að ég vinn með hana á hverjum degi. En netið var aðal grunaði, og ég þurfti að læra hvernig á að kemba það.

Sem betur fer elskar internetið þá sem vilja læra. Samsetningin af ping og tracert virtist vera nógu góð byrjun til að kemba netflutningsvandamál.

Í fyrsta lagi setti ég af stað PsPing til TCP tengi Alvins. Ég notaði sjálfgefnar stillingar - ekkert sérstakt. Af meira en þúsund pingum fór ekkert yfir 10 ms, að undanskildum því fyrsta til upphitunar. Þetta er í andstöðu við aukningu á leynd sem sést um 50 ms á 99. hundraðshlutanum: þar, fyrir hverjar 100 beiðnir, ættum við að hafa séð um eina beiðni með leynd upp á 50 ms.

Svo reyndi ég sporbraut: Það gæti verið vandamál á einum af hnútunum á leiðinni milli Alvin og viðskiptavinar. En rakarinn kom líka tómhentur til baka.

Þannig að það var ekki kóðinn minn, gRPC útfærslan eða netið sem olli seinkuninni. Ég var farin að hafa áhyggjur af því að ég myndi aldrei skilja þetta.

Nú á hvaða stýrikerfi erum við

gRPC mikið notað á Linux, en framandi á Windows. Ég ákvað að prófa tilraun, sem virkaði: Ég bjó til Linux sýndarvél, tók saman Alvin fyrir Linux og setti hana í notkun.

Og hér er það sem gerðist: Linux borðtennisþjónninn hafði ekki sömu tafir og svipaður Windows gestgjafi, þó að gagnagjafinn hafi ekki verið öðruvísi. Það kemur í ljós að vandamálið er í gRPC útfærslunni fyrir Windows.

Reiknirit Nagle

Allan þennan tíma hélt ég að mig vantaði fána gRPC. Nú skil ég hvað það er í raun og veru gRPC Windows fána vantar. Ég fann innra RPC bókasafn sem ég var fullviss um að myndi virka vel fyrir alla fána sett Aðlaðandi. Síðan bætti ég öllum þessum fánum við gRPC og setti Alvin á Windows, á pjatlaðan Windows borðtennisþjón!

Næstum Búið: Ég byrjaði að fjarlægja viðbættu fánana einn í einu þar til afturhvarfið kom aftur svo ég gæti fundið orsökina. Það var alræmt TCP_NODELAY, reikniritrofi Nagle.

Reiknirit Nagle reynir að draga úr fjölda pakka sem eru sendir um netkerfi með því að seinka sendingu skilaboða þar til pakkastærðin fer yfir ákveðinn fjölda bæta. Þó að þetta gæti verið gott fyrir meðalnotandann er það eyðileggjandi fyrir rauntímaþjóna þar sem stýrikerfið mun seinka sumum skilaboðum, sem veldur töfum á lágu QPS. U gRPC þetta flagg var sett í Linux útfærslu fyrir TCP fals, en ekki í Windows. Ég er þessi leiðrétt.

Ályktun

Hærri leynd við lágt QPS stafaði af hagræðingu stýrikerfisins. Eftir á að hyggja, greindi prófílgreining ekki leynd vegna þess að það var gert í kjarnaham frekar en í notendahamur. Ég veit ekki hvort hægt sé að fylgjast með reikniritinu hans Nagle í gegnum ETW fanga, en það væri áhugavert.

Hvað localhost tilraunina varðar, þá snerti hún líklega ekki raunverulegan netkóða og reiknirit Nagle keyrði ekki, þannig að leynd vandamálin hurfu þegar viðskiptavinurinn náði til Alvin í gegnum localhost.

Næst þegar þú sérð aukningu á leynd þar sem fjöldi beiðna á sekúndu minnkar, ætti reiknirit Nagle að vera á lista yfir grunaða!

Heimild: www.habr.com

Stundum er meira minna. Þegar dregið er úr álagi leiðir til aukinnar leynd