Dia duit gach duine! Dmitry Samsonov is ainm dom, táim ag obair mar phríomh-riarthóir córais ag Odnoklassniki. Tá níos mó ná 7 míle freastalaithe fisiceacha againn, 11 míle coimeádán inár scamall agus 200 feidhmchlár, atá i bhfoirmíochtaí éagsúla mar 700 braisle éagsúla. Reáchtálann formhór mór na bhfreastalaithe CentOS 7.
Ar 14 Lúnasa, 2018, foilsíodh faisnéis faoin leochaileacht FragmentSmack
() agus SegmentSmack (). Is leochaileachtaí iad seo a bhfuil veicteoir ionsaithe líonra acu agus scór sách ard (7.5), rud a bhagairt do shéanadh seirbhíse (DoS) de bharr ídithe acmhainne (LAP). Ní raibh socrú eithne do FragmentSmack molta ag an am sin; ina theannta sin, tháinig sé amach i bhfad níos déanaí ná foilsiú faisnéise faoin leochaileacht. Chun deireadh a chur le SegmentSmack, moladh an eithne a nuashonrú. Eisíodh an pacáiste nuashonraithe féin an lá céanna, ní raibh fágtha ach é a shuiteáil.
Níl, nílimid i gcoinne an eithne a nuashonrú ar chor ar bith! Mar sin féin, tá nuances ...
Conas a dhéanaimid nuashonrú ar an eithne ar tháirgeadh
Go ginearálta, níl aon rud casta:
- Íosluchtaigh pacáistí;
- Suiteáil iad ar roinnt freastalaithe (lena n-áirítear freastalaithe a óstáil ar ár scamall);
- Déan cinnte nach bhfuil aon rud briste;
- Déan cinnte go gcuirtear gach socrú caighdeánach eithne i bhfeidhm gan earráidí;
- Fan cúpla lá;
- Seiceáil feidhmíocht an fhreastalaí;
- Athraigh imscaradh freastalaithe nua chuig an eithne nua;
- Na freastalaithe go léir a nuashonrú de réir ionad sonraí (ionad sonraí amháin ag an am chun an éifeacht ar úsáideoirí a íoslaghdú i gcás fadhbanna);
- Atosaigh gach freastalaí.
Déan arís do gach brainse de na heithne atá againn. Faoi láthair tá sé:
- Stoc CentOS 7 3.10 - don chuid is mó de na freastalaithe rialta;
- Vanilla 4.19 - le haghaidh linne , toisc go dteastaíonn BFQ, BBR, srl .;
- Elrepo eithne-ml 5.2 - le haghaidh , mar gheall ar a úsáidtear 4.19 iompar éagobhsaí, ach tá na gnéithe céanna ag teastáil.
Mar a d’fhéadfadh a bheith agat faoi thuairim, tógann sé an t-am is faide chun na mílte freastalaithe a atosú. Ós rud é nach bhfuil gach leochaileacht ríthábhachtach do na freastalaithe go léir, ní atosaighimid ach iad siúd a bhfuil rochtain dhíreach orthu ón Idirlíon. Sa scamall, chun gan solúbthacht a theorannú, ní cheanglaímid coimeádáin atá inrochtana go seachtrach le freastalaithe aonair le heithne nua, ach atosaigh muid gach óstach gan eisceacht. Go fortunately, tá an nós imeachta ann níos simplí ná le freastalaithe rialta. Mar shampla, is féidir le coimeádáin gan stát bogadh go freastalaí eile le linn atosaigh.
Mar sin féin, tá a lán oibre fós, agus is féidir go dtógfaidh sé roinnt seachtainí, agus má tá aon fhadhbanna leis an leagan nua, suas le roinnt míonna. Tuigeann ionsaitheoirí é seo go han-mhaith, mar sin tá plean B ag teastáil uathu.
FragmentSmack/SegmentSmack. Réitigh oibre
Ar ámharaí an tsaoil, i gcás roinnt leochaileachtaí tá plean B den sórt sin ann, agus tugtar Workaround air. Go minic, is athrú é seo ar shocruithe eithne/feidhmchlár ar féidir leis an éifeacht fhéideartha a íoslaghdú nó deireadh a chur go hiomlán le saothrú leochaileachtaí.
I gcás FragmentSmack/SegmentSmack an Réiteach seo:
«Is féidir leat na luachanna réamhshocraithe 4MB agus 3MB a athrú i net.ipv4.ipfrag_high_thresh agus net.ipv4.ipfrag_low_thresh (agus a gcomhghleacaithe le haghaidh ipv6 net.ipv6.ipfrag_high_thresh agus net.ipv6.ipfrag_low_thresh) go 256 kB faoi seach íochtair. Léiríonn tástálacha titeann beag go suntasach in úsáid LAP le linn ionsaí ag brath ar chrua-earraí, socruithe agus coinníollacha. Mar sin féin, d'fhéadfadh roinnt tionchar feidhmíochta a bheith ann mar gheall ar ipfrag_high_thresh=192 bytes, mar ní féidir ach dhá bhlúire 262144K a chur isteach sa scuaine athchóimeála ag an am céanna. Mar shampla, tá an baol ann go mbrisfidh feidhmchláir a oibríonn le paicéid mhóra UDP'.
Na paraiméadair iad féin cur síos air mar seo a leanas:
ipfrag_high_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments.
ipfrag_low_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments before the kernel
begins to remove incomplete fragment queues to free up resources.
The kernel still accepts new fragments for defragmentation.
Níl UDPanna móra againn ar sheirbhísí táirgthe. Níl aon trácht ilroinnte ar an LAN; tá trácht ilroinnte ar an WAN, ach níl sé suntasach. Níl aon chomharthaí ann - is féidir leat Workaround a rolladh amach!
FragmentSmack/SegmentSmack. Chéad fola
Ba í an chéad fhadhb a tháinig orainn ná gur chuir coimeádáin scamall na socruithe nua i bhfeidhm uaireanta ach go páirteach (ach ipfrag_low_thresh), agus uaireanta níor chuir siad i bhfeidhm iad ar chor ar bith - níor tharla siad ach ag an tús. Níorbh fhéidir an fhadhb a atáirgeadh go cobhsaí (cuireadh na socruithe go léir i bhfeidhm de láimh gan aon deacrachtaí). Níl sé chomh furasta a thuiscint cén fáth a dtiteann an coimeádán ag an tús: níor aimsíodh aon earráidí. Bhí rud amháin cinnte: réitíonn rolladh siar na socruithe an fhadhb le tuairteanna coimeádáin.
Cén fáth nach bhfuil sé go leor Sysctl a chur i bhfeidhm ar an óstach? Cónaíonn an coimeádán ina líonra tiomnaithe Ainmspás, mar sin ar a laghad sa choimeádán difriúil ón ósta.
Cé go díreach a chuirtear socruithe Sysctl i bhfeidhm sa choimeádán? Ós rud é go bhfuil ár gcoimeádáin neamhphribhléideach, ní bheidh tú in ann aon socrú Sysctl a athrú trí dhul isteach sa choimeádán féin - níl a dhóthain cearta agat. Chun coimeádáin a rith, d'úsáid ár scamall ag an am sin Docker (anois ). Cuireadh paraiméadair an choimeádáin nua ar aghaidh chuig Docker tríd an API, lena n-áirítear na socruithe Sysctl riachtanacha.
Agus cuardach á dhéanamh trí na leaganacha, d'éirigh sé amach nár thug API Docker gach earráid ar ais (ar a laghad i leagan 1.10). Nuair a rinneamar iarracht an coimeádán a thosú trí “rith dugaí”, chonaiceamar ar a laghad rud éigin faoi dheireadh:
write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.
Níl luach an pharaiméadar bailí. Ach cén fáth? Agus cén fáth nach bhfuil sé bailí ach uaireanta? D'éirigh sé amach nach ráthaíonn Docker an t-ord ina gcuirtear paraiméadair Sysctl i bhfeidhm (is é an leagan tástálaithe is déanaí ná 1.13.1), agus mar sin uaireanta rinne ipfrag_high_thresh iarracht é a shocrú go 256K nuair a bhí ipfrag_low_thresh fós 3M, is é sin, bhí an uasteorainn níos ísle ná an teorainn níos ísle, rud ba chúis leis an earráid.
Ag an am sin, bhaineamar úsáid as ár meicníocht féin cheana féin chun an coimeádán a athchumrú tar éis tosaithe (an coimeádán a reo ina dhiaidh sin agus orduithe a fhorghníomhú in ainmspás an choimeádáin via ), agus chuireamar paraiméadair scríbhneoireachta Sysctl leis an gcuid seo freisin. Réitíodh an fhadhb.
FragmentSmack/SegmentSmack. An chéad fola fb2
Sula raibh am againn tuiscint a fháil ar úsáid Workaround sa scamall, thosaigh na chéad ghearáin annamha ó úsáideoirí ag teacht. Ag an am sin, bhí roinnt seachtainí caite ó cuireadh tús le húsáid Workaround ar na chéad fhreastalaithe. Léirigh an t-imscrúdú tosaigh go bhfuarthas gearáin i gcoinne seirbhísí aonair, agus ní i gcoinne freastalaithe uile na seirbhísí sin. Tá an fhadhb tar éis éirí thar a bheith éiginnte arís.
Ar an gcéad dul síos, rinneamar iarracht, ar ndóigh, na socruithe Sysctl a rolladh siar, ach ní raibh aon éifeacht aige seo. Níor chabhraigh ionramhálacha éagsúla leis an bhfreastalaí agus socruithe feidhmchláir ach an oiread. Chuidigh Atosaigh. Tá atógáil Linux chomh mínádúrtha agus a bhí sé de ghnáth do Windows sna seanlaethanta. Chabhraigh sé, áfach, agus rinneamar “glitch eithne” air agus na socruithe nua i Sysctl á gcur i bhfeidhm againn. Cé chomh suaibhreosach a bhí sé...
Trí seachtaine ina dhiaidh sin tháinig an fhadhb chun solais arís. Bhí cumraíocht na bhfreastalaithe seo simplí go leor: Nginx i mód seachfhreastalaí/cothromóir. Gan mórán tráchta. Nóta tosaigh nua: tá líon na n-earráidí 504 ar chliaint ag méadú gach lá (). Taispeánann an graf líon na n-earráidí 504 in aghaidh an lae don tseirbhís seo:
Tá na hearráidí go léir thart ar an inneall céanna - thart ar an gceann atá sa scamall. Bhí cuma mar seo ar an ngraf tomhaltas cuimhne le haghaidh blúirí pacáiste ar an inneall seo:
Tá sé seo ar cheann de na léirithe is soiléire ar an bhfadhb i graif córais oibriúcháin. Sa scamall, díreach ag an am céanna, socraíodh fadhb líonra eile le socruithe QoS (Rialú Tráchta). Ar an ngraf de thomhaltas cuimhne le haghaidh blúirí paicéad, d'fhéach sé díreach mar an gcéanna:
Bhí an toimhde simplí: má fhéachann siad mar an gcéanna ar na graif, tá an chúis chéanna acu. Ina theannta sin, tá aon fhadhbanna leis an gcineál seo cuimhne fíor-annamh.
Ba é croílár na faidhbe seasta ná gur úsáideamar an sceidealóir paicéad fq le socruithe réamhshocraithe i QoS. De réir réamhshocraithe, le haghaidh nasc amháin, ceadaíonn sé duit 100 paicéad a chur leis an scuaine, agus thosaigh roinnt naisc, i gcásanna ina raibh ganntanas cainéal, an scuaine a dhúnadh go hacmhainn. Sa chás seo, tá paicéid báite. I staitisticí tc (tc -s qdisc) is féidir é a fheiceáil mar seo:
qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
1024 flows (1021 inactive, 0 throttled)
0 gc, 0 highprio, 0 throttled, 464545 flows_plimit
Is éard is “464545 flows_plimit” ann na paicéid a laghdaíodh de bharr teorainn na scuaine d’aon nasc amháin a shárú, agus is é “titim 464545” suim na bpaicéad go léir a thit sa sceidealóir seo. Tar éis an fad scuaine a mhéadú go 1 míle agus na coimeádáin a atosú, stop an fhadhb a tharla. Is féidir leat suí siar agus smoothie a ól.
FragmentSmack/SegmentSmack. Fuil Deireanach
Ar an gcéad dul síos, roinnt míonna tar éis leochaileachtaí san eithne a fhógairt, tháinig réiteach le haghaidh FragmentSmack le feiceáil ar deireadh (lig dom i gcuimhne duit, mar aon leis an bhfógra i mí Lúnasa, gur scaoileadh réiteach amháin le haghaidh SegmentSmack), rud a thug deis dúinn Workaround a thréigean, rud a chuir go leor trioblóide orainn. Le linn an ama seo, d'éirigh linn cuid de na freastalaithe a aistriú chuig an eithne nua cheana féin, agus anois bhí orainn tosú ón tús. Cén fáth ar nuashonraíomar an eithne gan fanacht leis an socrú FragmentSmack? Is é fírinne an scéil gur tharla an próiseas chun cosaint a thabhairt i gcoinne na leochaileachtaí seo ag an am céanna (agus a chumasc) leis an bpróiseas chun CentOS féin a nuashonrú (a thógann fiú níos mó ama ná an t-eithne amháin a nuashonrú). Ina theannta sin, tá SegmentSmack leochaileacht níos contúirtí, agus a shocrú dó le feiceáil láithreach, mar sin rinne sé ciall ar aon nós. Mar sin féin, níorbh fhéidir linn an eithne ar CentOS a nuashonrú go simplí toisc nach raibh an leochaileacht FragmentSmack, a bhí le feiceáil le linn CentOS 7.5, socraithe ach i leagan 7.6, agus mar sin bhí orainn an nuashonrú a stopadh go 7.5 agus tosú arís leis an nuashonrú go 7.6. Agus a tharlaíonn sé seo freisin.
Ar an dara dul síos, tá gearáin úsáideoirí neamhchoitianta faoi fhadhbanna ar ais chugainn. Anois tá a fhios againn go cinnte go bhfuil baint acu go léir le huaslódáil comhaid ó chliaint chuig cuid dár bhfreastalaithe. Ina theannta sin, chuaigh líon an-bheag uaslódála ón mais iomlán trí na freastalaithe seo.
Mar is cuimhin linn ón scéal thuas, níor chabhraigh sé le tabhairt ar ais Sysctl. Chuidigh Atosaigh, ach go sealadach.
Níor baineadh amhras ar bith maidir le Sysctl, ach an uair seo bhí sé riachtanach an oiread eolais agus ab fhéidir a bhailiú. Bhí easpa cumais ollmhór ann freisin chun an fhadhb uaslódála a atáirgeadh ar an gcliant chun staidéar níos cruinne a dhéanamh ar a raibh ag tarlú.
Níor thug anailís ar na staitisticí agus na logaí go léir a bhí ar fáil níos gaire dúinn chun tuiscint a fháil ar cad a bhí ag tarlú. Bhí géar-easpa cumais ann chun an fhadhb a atáirgeadh chun nasc sonrach a “bhraistint”. Ar deireadh, d'éirigh leis na forbróirí, ag baint úsáide as leagan speisialta den fheidhmchlár, atáirgeadh cobhsaí fadhbanna a bhaint amach ar fheiste tástála nuair a bhí siad ceangailte trí Wi-Fi. Bhí sé seo chun cinn san imscrúdú. Cheangail an cliant le Nginx, a rinne seachfhreastalaí ar an inneall, a bhí mar ár bhfeidhmchlár Java.
Bhí an t-idirphlé le haghaidh fadhbanna mar seo (seasta ar thaobh seachfhreastalaí Nginx):
- Cliant: iarratas chun faisnéis a fháil faoi chomhad a íoslódáil.
- Freastalaí Java: freagra.
- Cliant: POST le comhad.
- Freastalaí Java: earráid.
Ag an am céanna, scríobhann an freastalaí Java chuig an logáil go bhfuarthas 0 beart sonraí ón gcliant, agus scríobhann seachfhreastalaí Nginx gur ghlac an t-iarratas níos mó ná 30 soicind (is é 30 soicind teorainn ama an iarratais chliaint). Cén fáth an teorainn ama agus cén fáth 0 beart? Ó thaobh HTTP de, oibríonn gach rud mar ba chóir, ach is cosúil go n-imíonn an POST leis an gcomhad ón líonra. Thairis sin, imíonn sé idir an cliant agus Nginx. Tá sé in am tú féin a lámh le Tcpdump! Ach ar dtús ní mór duit cumraíocht an líonra a thuiscint. Tá seachfhreastalaí Nginx taobh thiar den chothromóir L3 . Úsáidtear tolláin chun paicéid a sheachadadh ón iarmhéideoir L3 chuig an bhfreastalaí, a chuireann a cheanntásca leis na paicéid:
Sa chás seo, tagann an líonra chuig an bhfreastalaí seo i bhfoirm tráchta le clib Vlan, a chuireann a réimsí féin leis na paicéid freisin:
Agus is féidir leis an trácht seo a bheith ilroinnte freisin (an céatadán an-bheag sin den trácht ilroinnte isteach ar ar labhair muid faoi agus na rioscaí ó Workaround á measúnú), a athraíonn ábhar na gceanntásca freisin:
Arís eile: tá paicéid cuimsithe le clib Vlan, cuimsithe le tollán, ilroinnte. Chun tuiscint níos fearr a fháil ar conas a tharlaíonn sé seo, déanaimis an bealach paicéad a rianú ón gcliant go seachfhreastalaí Nginx.
- Sroicheann an paicéad an cothromóir L3. Le haghaidh ródú ceart laistigh den ionad sonraí, cuimsítear an paicéad i dtollán agus seoltar chuig an gcárta líonra é.
- Ós rud é nach bhfuil ceanntásca an phaicéad + tolláin oiriúnach don MTU, gearrtar an paicéad i blúirí agus seoltar chuig an líonra é.
- Nuair a fhaigheann an lasc tar éis an chothromóra L3 paicéad, cuireann sé clib Vlan leis agus cuireann sé ar aghaidh é.
- Feiceann an lasc os comhair an seachfhreastalaí Nginx (bunaithe ar na socruithe calafoirt) go bhfuil an freastalaí ag súil le paicéad Vlan-encapsulated, mar sin cuireann sé é mar atá, gan an chlib Vlan a bhaint.
- Glacann Linux blúirí de phacáistí aonair agus cumasc sé iad in aon phacáiste mór amháin.
- Ansin, téann an paicéad chuig an gcomhéadan Vlan, áit a mbaintear an chéad chiseal as - inchamhlú Vlan.
- Ansin cuireann Linux chuig an gcomhéadan Tollán é, áit a mbaintear ciseal eile uaidh - Ionchochlú Tollán.
Is é an deacracht atá ann é seo go léir a chur ar aghaidh mar pharaiméadair go tcpdump.
Tosaímid ón deireadh: an bhfuil paicéid IP glan (gan ceanntásca neamhriachtanach) ó chliaint, a bhfuil imchochlú vlan agus tolláin bainte?
tcpdump host <ip клиента>
Ní raibh a leithéid de phacáistí ar an bhfreastalaí. Mar sin caithfidh an fhadhb a bheith ann níos luaithe. An bhfuil aon phaicéid ann nach bhfuil ach imchochlú Vlan bainte iontu?
tcpdump ip[32:4]=0xx390x2xx
Is é 0xx390x2xx seoladh IP an chliaint i bhformáid heicsidheachúlach.
32:4 — seoladh agus fad na páirce ina bhfuil an SCR IP scríofa sa phaicéad Tonnadóir.
B'éigean an seoladh allamuigh a roghnú de réir fórsa brúidiúil, mar ar an Idirlíon scríobhann siad thart ar 40, 44, 50, 54, ach ní raibh aon seoladh IP ann. Is féidir leat breathnú freisin ar cheann de na paicéid i heics (an paraiméadar -xx nó -XX i tcpdump) agus ríomh an seoladh IP atá ar eolas agat.
An bhfuil blúirí paicéad gan imchochlú Vlan agus Tollán bainte?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Taispeánfaidh an draíocht seo na blúirí go léir dúinn, an ceann deireanach san áireamh. Is dócha, is féidir an rud céanna a scagadh le IP, ach ní dhearna mé iarracht, toisc nach bhfuil mórán paicéid den sórt sin ann, agus fuarthas na cinn a bhí de dhíth orm go héasca sa sreabhadh ginearálta. Seo iad:
14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........
14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
11.11.11.11 > 22.22.22.22: ip-proto-4
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............
Dhá bhlúire de phacáiste amháin iad seo (ID céanna 53652) le grianghraf (tá an focal Exif le feiceáil sa chéad phacáiste). Mar gheall ar an bhfíric go bhfuil pacáistí ag an leibhéal seo, ach nach bhfuil sa bhfoirm chumaisc sna dumpaí, tá an fhadhb go soiléir leis an tionól. Ar deireadh tá fianaise dhoiciméadach de seo!
Níor nocht an díchódóir paicéad aon fhadhbanna a chuirfeadh cosc ar an tógáil. Bain triail as anseo: . Ar dtús, nuair a dhéanann tú iarracht rud éigin a stuáil ansin, ní maith leis an díchódóir formáid an phacéid. Tharla sé go raibh roinnt dhá octets breise idir Srcmac agus Ethertype (nach mbaineann le faisnéis blúirí). Tar éis iad a bhaint, thosaigh an díchódóir ag obair. Mar sin féin, léirigh sé aon fadhbanna.
Cibé rud a déarfadh duine, ní bhfuarthas aon rud eile ach na Sysctl sin. Ní raibh fágtha ach bealach a aimsiú chun fadhbfhreastalaithe a aithint chun an scála a thuiscint agus cinneadh a dhéanamh ar ghníomhartha eile. Fuarthas an cuntar riachtanach tapa go leor:
netstat -s | grep "packet reassembles failed”
Tá sé i snmpd freisin faoi OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
“Líon na dteipeanna a bhraith an t-algartam ath-tionóil IP (ar chúis ar bith: am scoir, earráidí, srl.)."
I measc an ghrúpa freastalaithe ar a ndearnadh staidéar ar an bhfadhb, ar dhá cheann d'ardaigh an chuntar seo níos tapúla, ar dhá cheann níos moille, agus ar dhá cheann eile níor mhéadaigh sé ar chor ar bith. Nuair a chuirtear dinimic an chuntair seo i gcomparáid le dinimic na n-earráidí HTTP ar an bhfreastalaí Java, fuarthas comhghaol. Is é sin, d'fhéadfaí monatóireacht a dhéanamh ar an méadar.
Tá sé an-tábhachtach táscaire iontaofa fadhbanna a bheith agat ionas gur féidir leat a chinneadh go cruinn an gcabhraíonn rolladh siar Sysctl, mar ón scéal roimhe seo tá a fhios againn nach féidir é seo a thuiscint láithreach ón iarratas. Ligfeadh an táscaire seo dúinn gach fadhb a bhaineann le táirgeadh a aithint sula n-aimsíonn úsáideoirí é.
Tar éis Sysctl a rolladh ar ais, stop na hearráidí monatóireachta, dá bhrí sin cruthaíodh cúis na bhfadhbanna, chomh maith leis an bhfíric go gcuidíonn an t-aischur.
Rinneamar na socruithe ilroinnte a rolladh siar ar fhreastalaithe eile, áit ar tháinig monatóireacht nua i bhfeidhm, agus áit éigin leithdháileamar fiú níos mó cuimhne le haghaidh blúirí ná mar a bhí roimhe seo (staitisticí UDP a bhí anseo, nach raibh a caillteanas páirteach faoi deara i gcoinne an chúlra ginearálta) .
Na ceisteanna is tábhachtaí
Cén fáth a bhfuil paicéid ilroinnte ar ár n-cothromóir L3? Is iad SYN agus ACK an chuid is mó de na paicéid a thagann ó úsáideoirí go cothromóirí. Tá méideanna na bpacáistí seo beag. Ach ós rud é go bhfuil sciar na bpacáistí den sórt sin an-mhór, i gcoinne a gcúlra níor thugamar faoi deara láithreacht paicéid mhóra a thosaigh ag scoilteadh.
Ba é an chúis script cumraíochta briste ar fhreastalaithe le comhéadain Vlan (ní raibh mórán freastalaithe le trácht clibeáilte á dtáirgeadh ag an am sin). Ligeann Advmss dúinn an t-eolas a chur in iúl don chliant gur chóir go mbeadh paicéid inár dtreo níos lú i méid ionas nach gcaithfidh siad a bheith ilroinnte tar éis ceanntásca tolláin a cheangal leo.
Cén fáth nár chabhraigh aisíocaíocht Sysctl, ach nár chabhraigh an t-atosú? Ag rolladh siar D'athraigh Sysctl an méid cuimhne a bhí ar fáil chun pacáistí a chumasc. Ag an am céanna, is cosúil go raibh moill ar naisc mar thoradh ar an ró-shreabhadh cuimhne le haghaidh blúirí, rud a d'fhág go raibh moill fhada ar na blúirí sa scuaine. Is é sin, chuaigh an próiseas i dtimthriallta.
Ghlan an atosaigh an chuimhne agus d'fhill gach rud in ord.
An raibh sé indéanta a dhéanamh gan Workaround? Is féidir, ach tá an baol ann go bhfágfar úsáideoirí gan seirbhís i gcás ionsaí. Ar ndóigh, tháinig fadhbanna éagsúla le húsáid Workaround, lena n-áirítear moilliú ar cheann de na seirbhísí d’úsáideoirí, ach mar sin féin creidimid go raibh údar maith leis na gníomhartha.
Míle buíochas le Andrey Timofeev () le cúnamh a thabhairt chun an t-imscrúdú a sheoladh, chomh maith le Alexey Krenev () - don obair titanic chun Centos agus eithne a nuashonrú ar fhreastalaithe. Próiseas a bhí sa chás seo le tosú ón tús arís agus arís eile, agus is é sin an fáth a tharraing sé ar aghaidh ar feadh míonna fada.
Foinse: will.com