In bezala mezu gehienak, arazo bat dago banatutako zerbitzu batekin, dei diezaiogun zerbitzu honi Alvin. Oraingoan nik ez nuen arazoa deskubritu, jakinarazi zidaten bezeroaren aldeko mutilek.

Egun batean, atsekabeko mezu elektroniko bat esnatu nintzen Alvinekin atzerapen luzeak zirela eta, etorkizun hurbilean abiarazteko asmoa genuen. Zehazki, bezeroak 99. pertzentilaren latentzia izan zuen 50 ms-ko eskualdean, gure latentzia-aurrekontua oso gainetik. Hau harrigarria izan zen, zerbitzua asko probatu nuelako, batez ere latentziari dagokionez, ohiko kexa dena.

Alvin proban jarri aurretik, esperimentu asko egin nituen 40 kontsulta segundoko (QPS), guztiak 10 ms baino gutxiagoko latentzia erakutsiz. Prest nengoen haien emaitzekin ados ez nengoela adierazteko. Baina gutunari beste begirada bat emanez, zerbait berria nabaritu nuen: ez nituen zehazki probatu aipatu zituzten baldintzak, haien QPS nirea baino askoz txikiagoa zen. 40k QPS-n probatu nuen, baina 1k-n bakarrik dute. Beste esperimentu bat egin nuen, oraingoan QPS baxuago batekin, haiek baretzeko.

Honi buruz blogean ari naizenez, ziurrenik dagoeneko asmatu duzu haien zenbakiak zuzenak zirela. Nire bezero birtuala behin eta berriro probatu nuen emaitza berarekin: eskaera kopuru baxuak latentzia areagotzeaz gain, 10 ms-tik gorako latentzia duten eskaerak areagotzen ditu. Beste era batera esanda, 40k QPS-n 50ms-tik gorako segundoko 50 eskaera inguru bazeuden, orduan 1k QPS-n 100ms-tik gorako 50 eskaera zeuden segundo bakoitzean. Paradoxa!

Bilaketa murriztea

Osagai asko dituen sistema banatu batean latentzia arazo baten aurrean, lehen urratsa susmagarrien zerrenda labur bat sortzea da. Sakon dezagun pixka bat Alvin-en arkitekturan:

Abiapuntu ona egindako I/O trantsizioen zerrenda bat da (sare-deiak/disko-bilaketa, etab.). Saia gaitezen atzerapena non dagoen asmatzen. Bezeroarekiko I/O bistakoaz gain, Alvinek urrats gehigarri bat egiten du: datu biltegira sartzen da. Hala ere, biltegiratze honek Alvin-en kluster berean funtzionatzen du, beraz, hango latentzia bezeroarekin baino txikiagoa izan beharko litzateke. Beraz, susmagarrien zerrenda:

1. Bezeroaren sareko deia Alvin-i.
2. Alvin-en sareko deia datu biltegira.
3. Bilatu diskoan datu biltegian.
4. Sare-deia datu biltegitik Alvin-i.
5. Alvin-ek bezero bati sareko deia.

Saia gaitezen puntu batzuk ezabatzen.

Datuak biltegiratzeak ez du horrekin zerikusirik

Egin nuen lehenengo gauza Alvin eskaerak prozesatzen ez dituen ping-ping zerbitzari batera bihurtzea izan zen. Eskaera jasotzen duenean, erantzun huts bat itzultzen du. Latentzia murrizten bada, Alvin-en edo datu biltegiaren inplementazioan akats bat ez da ezer entzuten. Lehenengo esperimentuan grafiko hau lortuko dugu:

Ikus dezakezunez, ez dago hobekuntzarik ping-ping zerbitzaria erabiltzean. Horrek esan nahi du datu biltegiak ez duela latentzia handitzen, eta susmagarrien zerrenda erdira murrizten dela:

1. Bezeroaren sareko deia Alvin-i.
2. Alvin-ek bezero bati sareko deia.

Bikaina! Zerrenda azkar murrizten ari da. Arrazoia ia asmatu nuela uste nuen.

gRPC

Jokalari berri bat aurkezteko unea da: gRPC. Hau Google-ren kode irekiko liburutegia da, prozesuan komunikaziorako RPC... Nahiz gRPC ondo optimizatuta eta oso erabilia, hau izan zen tamaina honetako sistema batean erabiltzen nuen lehenengo aldia eta nire inplementazioa ezin hobea izango zela espero nuen - gutxienez.

erabilgarritasuna gRPC pila batean galdera berri bat sortu zen: agian nire ezarpena edo ni neu izango da gRPC latentzia arazoa eragiten? Susmagarri berri bat zerrendara gehitzea:

1. Bezeroak liburutegira deitzen du gRPC
2. Liburutegia gRPC sareko deia egiten dio liburutegiari bezeroari gRPC zerbitzarian
3. Liburutegia gRPC Alvin-ekin harremanetan jarri (ez da eragiketarik ping-pong zerbitzariaren kasuan)

Kodea nolakoa den jakiteko, nire bezero/Alvin inplementazioa ez da oso desberdina bezero-zerbitzariaren aldean. asinkronizazio adibideak.

Oharra: goiko zerrenda zertxobait sinplifikatu da gRPC zure (txantiloi?) hari-eredua erabiltzea posible egiten du, zeinetan exekuzio-pila nahastuta dagoen. gRPC eta erabiltzaileen ezarpena. Sinpletasunaren mesedetan, eredu honi eutsiko diogu.

Profilak dena konponduko du

Datu biltegiak markatuta, ia amaituta nengoela pentsatu nuen: “Orain erraza da! Aplikatu dezagun profila eta jakin dezagun non gertatzen den atzerapena». I zehaztasun profilaren zale handia, CPUak oso azkarrak direlako eta gehienetan ez direlako botila-lepoa. Atzerapen gehienak prozesadoreak prozesatzeari utzi behar dionean gertatzen dira beste zerbait egiteko. PUZaren profil zehatzak hori egiten du: dena zehaztasunez erregistratzen du testuinguru-aldaketak eta argi uzten du non gertatzen diren atzerapenak.

Lau profil hartu nituen: QPS handiko (latentzia baxua) eta QPS baxuko (latentzia handia) ping-pong zerbitzari batekin, bai bezeroaren aldetik eta baita zerbitzariaren aldetik ere. Eta badaezpada, lagin-prozesadorearen profil bat ere hartu nuen. Profilak alderatzean, normalean dei-pila anormal bat bilatzen dut. Esaterako, latentzia handiko alde txarrean testuinguru-aldaketa askoz gehiago daude (10 aldiz edo gehiago). Baina nire kasuan, testuinguru-aldaketen kopurua ia berdina zen. Nire izurako, han ez zegoen ezer esanguratsurik.

Arazketa gehigarria

etsi nengoen. Ez nekien zer beste tresna erabil nezakeen, eta nire hurrengo plana izan zen funtsean esperimentuak aldakuntza ezberdinekin errepikatzea arazoa argi diagnostikatzea baino.

Zer balitz

Hasieratik 50 ms-ko latentzia espezifikoak kezkatzen ninduen. Hau oso garai handia da. Kodetik zatiak moztuko nituzkeela erabaki nuen akats hau zein zatik eragiten zuen jakin arte. Ondoren, funtzionatu zuen esperimentu bat etorri zen.

Ohi bezala, atzera begiratuta badirudi dena agerikoa zela. Bezeroa Alvin-en makina berean jarri nuen eta eskaera bat bidali nion localhost. Eta latentziaren igoera desagertu egin da!

Zerbait gaizki zegoen sarean.

Sare ingeniari trebetasunak ikastea

Aitortu behar dut: sareko teknologien inguruko ezagutza izugarria da, batez ere haiekin egunero lan egiten dudala kontuan hartuta. Baina sarea zen susmagarri nagusia, eta nola arazketan ikasi behar nuen.

Zorionez, Internetek maite ditu ikasi nahi dutenak. Ping eta tracert konbinazioak sareko garraio-arazoak arazketarako hasiera nahiko ona iruditu zitzaizkion.

Lehenik eta behin, martxan jarri nuen PsPing Alvin-en TCP atakara. Ezarpen lehenetsiak erabili ditut - ezer berezirik ez. Mila ping baino gehiagotan, inork ez zuen 10ms baino gehiago gainditu, berotzen lehena izan ezik. Hau 50. pertzentilean 99 ms-ko latentziaren igoeraren kontrakoa da: bertan, 100 eskaera bakoitzeko, 50 ms-ko latentzia duen eskaera bat ikusi beharko genuke.

Orduan saiatu nintzen arrastoa: Arazo bat egon daiteke Alvin eta bezeroaren arteko ibilbidean dauden nodoetako batean. Baina trazatzailea ere esku hutsik itzuli zen.

Beraz, ez zen nire kodea, gRPC inplementazioa edo sarea atzerapena eragiten zuena. Hau inoiz ulertuko ez nuelako kezkatzen hasia nintzen.

Orain zein OStan gaude

gRPC Linux-en oso erabilia, baina exotikoa Windows-en. Esperimentu bat probatzea erabaki nuen, eta horrek funtzionatu zuen: Linux makina birtual bat sortu nuen, Alvin Linuxerako konpilatu eta zabaldu nuen.

Eta hona zer gertatu zen: Linux ping-pong zerbitzariak ez zituen antzeko Windows ostalari baten atzerapen berdinak izan, nahiz eta datu-iturburua ez zen ezberdina izan. Arazoa Windows-erako gRPC inplementazioan dagoela ematen du.

Nagle-ren algoritmoa

Denbora honetan guztian bandera bat falta zitzaidala pentsatu nuen gRPC. Orain ulertzen dut zer den benetan gRPC Windows bandera falta da. Barneko RPC liburutegi bat aurkitu nuen, marka guztietarako ondo funtzionatuko zuela ziur nengoela Winsock. Ondoren, bandera hauek guztiak gRPC-ra gehitu eta Alvin Windows-en zabaldu nuen, Windows-eko ping-pong zerbitzari batean adabakituta!

ia Eginda: gehitutako banderak banan-banan kentzen hasi nintzen erregresioa itzuli zen arte, kausa zehaztu ahal izateko. Gaiztoa zen TCP_NODELAY, Nagle-ren algoritmoaren etengailua.

Nagle-ren algoritmoa sare batean bidalitako pakete kopurua murrizten saiatzen da mezuen transmisioa atzeratuz paketearen tamainak byte kopuru jakin bat gainditu arte. Hau atsegina izan daitekeen batez besteko erabiltzailearentzat, suntsitzailea da denbora errealeko zerbitzarientzat, OSak mezu batzuk atzeratuko dituelako, QPS baxuan atzerapenak eraginez. U gRPC bandera hau TCP socketetarako Linux inplementazioan ezarri zen, baina ez Windows-en. Ni hau naiz zuzenduta.

Ondorioa

QPS baxuan latentzia handiagoa sistema eragilearen optimizazioak eragin zuen. Atzera begira, profilak ez zuen latentzia hauteman, nukleo moduan egin baitzen erabiltzaile modua. Ez dakit Nagleren algoritmoa ETW harrapaketen bidez behatu daitekeen, baina interesgarria izango litzateke.

Localhost esperimentuari dagokionez, ziurrenik ez zuen sareko benetako kodea ukitu eta Nagle-ren algoritmoa ez zen exekutatu, beraz, latentzia arazoak desagertu ziren bezeroa Alvin-era iritsi zenean localhost bidez.

Latentzia handitzea ikusten duzun hurrengoan segundoko eskaera kopurua murrizten den heinean, Nagle-ren algoritmoak susmagarrien zerrendan egon beharko luke!

Iturria: www.habr.com