Fel yn y rhan fwyaf o bostiadau, mae problem gyda gwasanaeth dosbarthedig, gadewch i ni alw'r gwasanaeth hwn yn Alvin. Y tro hwn ni wnes i ddarganfod y broblem fy hun, fe wnaeth y dynion o ochr y cleient fy hysbysu.

Un diwrnod deffrais i e-bost anfodlon oherwydd oedi hir gydag Alvin, yr oeddem yn bwriadu ei lansio yn y dyfodol agos. Yn benodol, profodd y cleient 99fed canradd hwyrni tua 50 ms, ymhell uwchlaw ein cyllideb hwyrni. Roedd hyn yn syndod gan i mi brofi'r gwasanaeth yn helaeth, yn enwedig ar hwyrni, sy'n gŵyn gyffredin.

Cyn i mi roi Alvin i mewn i brofi, cynhaliais lawer o arbrofion gydag ymholiadau 40k yr eiliad (QPS), i gyd yn dangos hwyrni o lai na 10ms. Roeddwn yn barod i ddatgan nad oeddwn yn cytuno â’u canlyniadau. Ond o edrych eto ar y llythyr, sylwais ar rywbeth newydd: nid oeddwn wedi profi'n union yr amodau a grybwyllwyd ganddynt, roedd eu QPS yn llawer is na fy un i. Profais ar 40k QPS, ond dim ond ar 1k oeddent. Cynhaliais arbrawf arall, y tro hwn gyda QPS is, dim ond i'w tawelu.

Gan fy mod yn blogio am hyn, mae'n debyg eich bod eisoes wedi darganfod bod eu niferoedd yn gywir. Profais fy nghleient rhithwir dro ar ôl tro, gyda'r un canlyniad: mae nifer isel o geisiadau nid yn unig yn cynyddu'r hwyrni, ond yn cynyddu nifer y ceisiadau gyda hwyrni o fwy na 10 ms. Mewn geiriau eraill, os ar 40k QPS roedd tua 50 cais yr eiliad yn fwy na 50 ms, yna ar 1k QPS roedd 100 o geisiadau dros 50 ms bob eiliad. Paradocs!

Culhau'r chwiliad

Wrth wynebu problem hwyrni mewn system ddosbarthedig gyda llawer o gydrannau, y cam cyntaf yw creu rhestr fer o bobl dan amheuaeth. Gadewch i ni gloddio ychydig yn ddyfnach i bensaernïaeth Alvin:

Man cychwyn da yw rhestr o drawsnewidiadau I/O wedi'u cwblhau (galwadau rhwydwaith/edrych ar ddisgiau, ac ati). Gadewch i ni geisio darganfod ble mae'r oedi. Heblaw am yr I/O amlwg gyda'r cleient, mae Alvin yn cymryd cam ychwanegol: mae'n cyrchu'r storfa ddata. Fodd bynnag, mae'r storfa hon yn gweithredu yn yr un clwstwr ag Alvin, felly dylai'r hwyrni fod yn llai na gyda'r cleient. Felly, mae'r rhestr o bobl a ddrwgdybir:

1. Galwad rhwydwaith gan y cleient i Alvin.
2. Galwad rhwydwaith o Alvin i'r storfa ddata.
3. Chwiliwch ar ddisg yn y storfa ddata.
4. Galwad rhwydwaith o'r warws data i Alvin.
5. Galwad rhwydwaith gan Alvin i gleient.

Gadewch i ni geisio croesi allan rhai pwyntiau.

Nid oes gan storio data unrhyw beth i'w wneud ag ef

Y peth cyntaf wnes i oedd trosi Alvin i weinydd ping-ping nad yw'n prosesu ceisiadau. Pan fydd yn derbyn cais, mae'n dychwelyd ymateb gwag. Os yw'r hwyrni'n lleihau, yna nid yw byg yng ngweithrediad Alvin neu warws data yn ddim byd arall. Yn yr arbrawf cyntaf rydym yn cael y graff canlynol:

Fel y gwelwch, nid oes unrhyw welliant wrth ddefnyddio'r gweinydd ping-ping. Mae hyn yn golygu nad yw'r warws data yn cynyddu hwyrni, ac mae'r rhestr o bobl a ddrwgdybir yn cael ei thorri yn ei hanner:

1. Galwad rhwydwaith gan y cleient i Alvin.
2. Galwad rhwydwaith gan Alvin i gleient.

Gwych! Mae'r rhestr yn crebachu'n gyflym. Roeddwn i'n meddwl fy mod bron wedi cyfrifo'r rheswm.

gRPC

Nawr yw'r amser i'ch cyflwyno i chwaraewr newydd: gRPC. Mae hon yn llyfrgell ffynhonnell agored gan Google ar gyfer cyfathrebu yn y broses CPR. Ond gRPC wedi'i optimeiddio'n dda ac yn cael ei ddefnyddio'n helaeth, dyma'r tro cyntaf i mi ei ddefnyddio ar system o'r maint hwn ac roeddwn yn disgwyl i'm gweithrediad fod yn is-optimaidd - a dweud y lleiaf.

argaeledd gRPC yn y pentwr esgor ar gwestiwn newydd: efallai mai fy ngweithrediad i neu fi fy hun ydyw gRPC achosi problem hwyrni? Ychwanegu rhywun sydd dan amheuaeth newydd at y rhestr:

1. Mae'r cleient yn galw'r llyfrgell gRPC
2. Llyfrgell gRPC yn gwneud galwad rhwydwaith i'r llyfrgell ar y cleient gRPC ar y gweinydd
3. Llyfrgell gRPC cysylltu ag Alvin (dim gweithrediad rhag ofn gweinydd ping-pong)

I roi syniad i chi o sut olwg sydd ar y cod, nid yw fy ngweithrediad cleient/Alvin yn llawer gwahanol i'r rhai cleient-gweinydd enghreifftiau async.

Nodyn: Mae'r rhestr uchod ychydig yn symlach oherwydd gRPC yn ei gwneud hi'n bosibl defnyddio'ch model edafu (templed?) eich hun, lle mae'r pentwr gweithredu wedi'i gydblethu gRPC a gweithrediad defnyddwyr. Er mwyn symlrwydd, byddwn yn cadw at y model hwn.

Bydd proffilio yn trwsio popeth

Ar ôl croesi'r storfeydd data, roeddwn i'n meddwl fy mod bron â gorffen: “Nawr mae'n hawdd! Gadewch i ni gymhwyso'r proffil a darganfod ble mae'r oedi yn digwydd. ” i gefnogwr mawr o broffilio manwl gywir, oherwydd bod CPUs yn gyflym iawn ac yn amlaf nid dyna'r dagfa. Mae'r rhan fwyaf o oedi yn digwydd pan fydd yn rhaid i'r prosesydd roi'r gorau i brosesu i wneud rhywbeth arall. Mae Proffilio CPU Cywir yn gwneud hynny'n union: mae'n cofnodi popeth yn gywir switshis cyd-destun ac yn ei gwneud yn glir lle mae oedi yn digwydd.

Cymerais bedwar proffil: gyda QPS uchel (latency isel) a gyda gweinydd ping-pong gyda QPS isel (latency uchel), ar ochr y cleient ac ar ochr y gweinydd. A rhag ofn, cymerais broffil prosesydd sampl hefyd. Wrth gymharu proffiliau, rwyf fel arfer yn edrych am stac galwadau afreolaidd. Er enghraifft, ar yr ochr ddrwg gyda hwyrni uchel mae llawer mwy o switshis cyd-destun (10 gwaith neu fwy). Ond yn fy achos i, roedd nifer y switshis cyd-destun bron yr un peth. Er mawr arswyd i mi, doedd dim byd arwyddocaol yno.

Dadfygio Ychwanegol

Roeddwn i'n anobeithiol. Doeddwn i ddim yn gwybod pa offer eraill y gallwn eu defnyddio, a fy nghynllun nesaf yn ei hanfod oedd ailadrodd yr arbrofion gyda gwahanol amrywiadau yn hytrach na gwneud diagnosis clir o'r broblem.

Beth os

O'r cychwyn cyntaf, roeddwn i'n pryderu am y 50ms hwyrni penodol. Mae hwn yn amser mawr iawn. Penderfynais y byddwn yn torri talpiau allan o'r cod nes y gallwn ddarganfod yn union pa ran oedd yn achosi'r gwall hwn. Yna daeth arbrawf a weithiodd.

Yn ôl yr arfer, o edrych yn ôl mae'n ymddangos bod popeth yn amlwg. Gosodais y cleient ar yr un peiriant ag Alvin - ac anfon cais at localhost. Ac mae'r cynnydd mewn hwyrni wedi diflannu!

Roedd rhywbeth o'i le ar y rhwydwaith.

Dysgu sgiliau peiriannydd rhwydwaith

Rhaid imi gyfaddef: mae fy ngwybodaeth am dechnolegau rhwydwaith yn ofnadwy, yn enwedig o ystyried y ffaith fy mod yn gweithio gyda nhw bob dydd. Ond y rhwydwaith oedd y prif ddrwgdybiedig, ac roedd angen i mi ddysgu sut i'w ddadfygio.

Yn ffodus, mae'r Rhyngrwyd yn caru'r rhai sydd eisiau dysgu. Roedd y cyfuniad o ping a thracert yn ymddangos fel dechrau digon da i ddadfygio problemau trafnidiaeth rhwydwaith.

Yn gyntaf, lansiais PsPing i borthladd TCP Alvin. Defnyddiais y gosodiadau diofyn - dim byd arbennig. O blith mwy na mil o pings, nid oedd yr un ohonynt yn fwy na 10 ms, ac eithrio'r un cyntaf ar gyfer cynhesu. Mae hyn yn groes i’r cynnydd a welwyd mewn hwyrni o 50 ms ar y 99ain ganradd: yno, am bob 100 o geisiadau, dylem fod wedi gweld tua un cais gyda hwyrni o 50 ms.

Yna ceisiais olrheiniwr: Efallai y bydd problem yn un o'r nodau ar hyd y llwybr rhwng Alvin a'r cleient. Ond dychwelodd yr olrheiniwr yn waglaw hefyd.

Felly nid fy nghod i, gweithrediad y GRPC, na'r rhwydwaith oedd yn achosi'r oedi. Roeddwn yn dechrau poeni na fyddwn byth yn deall hyn.

Nawr pa OS ydym ni arno

gRPC a ddefnyddir yn eang ar Linux, ond egsotig ar Windows. Penderfynais roi cynnig ar arbrawf, a weithiodd: fe wnes i greu peiriant rhithwir Linux, llunio Alvin ar gyfer Linux, a'i ddefnyddio.

A dyma beth ddigwyddodd: nid oedd gan y gweinydd ping-pong Linux yr un oedi â gwesteiwr Windows tebyg, er nad oedd y ffynhonnell ddata yn wahanol. Mae'n ymddangos bod y broblem yng ngweithrediad gRPC ar gyfer Windows.

Algorithm Nagle

Yr holl amser hwn roeddwn i'n meddwl fy mod yn colli baner gRPC. Nawr rwy'n deall beth ydyw mewn gwirionedd gRPC Ffenestri baner ar goll. Deuthum o hyd i lyfrgell RPC fewnol yr oeddwn yn hyderus y byddai'n gweithio'n dda ar gyfer yr holl fflagiau a osodwyd Winsock. Yna ychwanegais yr holl fflagiau hyn at gRPC a gosod Alvin ar Windows, mewn gweinydd ping-pong glytiog Windows!

Bron Wedi'i wneud: Dechreuais dynnu'r baneri ychwanegol un ar y tro nes i'r atchweliad ddychwelyd er mwyn i mi allu nodi'r achos. Roedd yn enwog TCP_NODELAY, switsh algorithm Nagle.

Algorithm Nagle ymdrechion i leihau nifer y pecynnau a anfonir dros rwydwaith trwy ohirio trosglwyddo negeseuon nes bod maint y pecyn yn fwy na nifer penodol o beit. Er y gallai hyn fod yn braf i'r defnyddiwr cyffredin, mae'n ddinistriol i weinyddion amser real gan y bydd yr OS yn gohirio rhai negeseuon, gan achosi oedi ar QPS isel. U gRPC gosodwyd y faner hon yng ngweithrediad Linux ar gyfer socedi TCP, ond nid yn Windows. Fi yw hwn cywiro.

Casgliad

Achoswyd y hwyrni uwch ar QPS isel gan optimeiddio OS. Wrth edrych yn ôl, ni chanfu proffilio hwyrni oherwydd ei fod yn cael ei wneud yn y modd cnewyllyn yn hytrach nag yn modd defnyddiwr. Nid wyf yn gwybod a ellir arsylwi algorithm Nagle trwy ddal ETW, ond byddai'n ddiddorol.

O ran yr arbrawf localhost, mae'n debyg nad oedd yn cyffwrdd â'r cod rhwydweithio gwirioneddol ac nid oedd algorithm Nagle yn rhedeg, felly aeth y materion hwyrni i ffwrdd pan gyrhaeddodd y cleient Alvin trwy localhost.

Y tro nesaf y byddwch yn gweld cynnydd mewn hwyrni wrth i nifer y ceisiadau yr eiliad leihau, dylai algorithm Nagle fod ar eich rhestr o bobl a ddrwgdybir!

Ffynhonnell: hab.com