Ji ber vê yekê hûn metrîkan berhev dikin. Weke ku em in. Em metrîkan jî berhev dikin. Bê guman, ji bo karsaziyê pêwîst e. Îro em ê li ser zencîreya yekem a pergala xweya çavdêriyê biaxivin - serverek kombûnê ya lihevhatî ya statsd , çima me ew nivîsand û çima me dev ji brûbek berda.
Ji gotarên me yên berê (, ) hûn dikarin fêr bibin ku heya demekê me bi karanîna nîşanan berhev kir . Ew bi C-yê hatî nivîsandin. Ji hêla kodê ve, ew bi qasî fîşekek hêsan e (ev girîng e dema ku hûn dixwazin tevkariyê bikin) û ya herî girîng, ew cildên me yên 2 mîlyon metrîkên per second (MPS) di lûtkeyê de digire. bê pirsgirêk. Di belgeyê de ji bo 4 mîlyon MPS bi stêrkek piştgirî tê gotin. Ev tê vê wateyê ku heke hûn torê li Linux-ê rast mîheng bikin hûn ê jimareya diyarkirî bistînin. (Em nizanin ka hûn dikarin çend MPS-ê bistînin ger hûn torê wekî xwe bihêlin). Tevî van avantajên, me gelek giliyên cidî li ser brubeck hebûn.
Îdîa 1. Github, pêşdebirê projeyê, piştgiriya wê rawestand: weşandina paç û rastkirin, pejirandina ya me û (ne tenê ya me) PR. Di van çend mehên dawî de (li cihekî ji Sibat-Adar 2018), çalakî ji nû ve dest pê kir, lê berî wê hema hema 2 sal aramiyek tam hebû. Ji bilî vê, proje tê pêşxistin , ku dikare bibe astengiyek cidî ji bo danasîna taybetmendiyên nû.
Îdîa 2. Rastbûna hesabên. Brubeck ji bo kombûnê bi tevahî 65536 nirx berhev dike. Di rewşa me de, ji bo hin metrikan, di heyama berhevkirinê de (30 çirke), dibe ku nirxên pir zêde bigihîjin (1 di lûtkeyê de). Di encama vê nimûneyê de, nirxên herî zêde û herî kêm bêkêr xuya dikin. Mînakî, bi vî rengî:
Wekî ku bû
Divê çawa bûya
Ji ber heman sedemê, mîqdar bi gelemperî xelet têne hesibandin. Li vir xeletiyek bi floatek 32-bit zêde bikin, ku bi gelemperî dema ku metrîkek xuya bêguneh distîne serverê dişîne segfault, û her tişt mezin dibe. Bi awayê, xeletî nehatiye rast kirin.
Û dawiyê Daxwaza X. Di dema nivîsandinê de, em amade ne ku wê pêşkêşî her 14 pêkanînên statsd yên kêm-zêde kar bikin ku me karîbû bibînin. Ka em bifikirin ku hin binesaziyek yekane ew qas mezin bûye ku qebûl kirina 4 mîlyon MPS êdî têrê nake. An jî heke ew hîn mezin nebûbe, lê metrîk jixwe ji we re ew qas girîng in ku tewra di nexşeyan de 2-3 hûrdeman hûrgulî jî dikare bibe krîtîk û di nav rêvebiran de bibe sedema pevçûnên depresyonê yên bêserûber. Ji ber ku dermankirina depresyonê karekî bê spas e, çareseriyên teknîkî hewce ne.
Pêşîn, tolerasyona xeletiyê, da ku pirsgirêkek ji nişka ve li ser serverê nebe sedema apokalypsek zombî ya derûnî ya li nivîsgehê. Ya duyemîn, pîvandina ku bikaribe zêdetirî 4 mîlyon MPS-ê qebûl bike, bêyî ku kûr li stûna torê ya Linux-ê bikole û bi aramî "bi firehî" bi mezinahiya hewce mezin bibe.
Ji ber ku cîhê me ji bo pîvandinê hebû, me biryar da ku em bi tolerasyona xeletiyê dest pê bikin. "JI DOR! Toleransa xeletiyê! Ew hêsan e, em dikarin wiya bikin, "me fikirîn û 2 server dan destpêkirin, li ser her yekê kopiyek brubeck rakir. Ji bo vê yekê, me neçar ma ku seyrûsefera bi metrîkan li herdu serveran kopî bikin û ji bo vê jî binivîsin . Me bi vê yekê pirsgirêka tolerasyona xeletiyê çareser kir, lê ... ne pir baş. Di destpêkê de her tişt pir xweş xuya bû: her brubek guhertoya xwe ya berhevkirinê berhev dike, her 30 çirkeyan carekê daneyan ji Graphite re dinivîse, navbera kevin dinivîse (ev li aliyê Graphite tê kirin). Ger serverek ji nişkê ve têk biçe, me her gav yekî duyemîn heye ku bi kopiya xwe ya daneyên berhevkirî re heye. Lê li vir pirsgirêk ev e: heke server têk nebe, "dît" li ser grafiyan xuya dike. Ev ji ber vê yekê ye ku navberên 30-saniyeyên brubeck ne hevdemkirî ne, û di dema qezayê de yek ji wan nayê nivîsandin. Dema ku servera duyemîn dest pê dike, heman tişt diqewime. Pir tolerans, lê ez çêtir dixwazim! Pirsgirêka mezinbûnê jî ji holê ranebûye. Hemî metrîk hîn jî "difirin" berbi serverek yekane, û ji ber vê yekê em bi heman 2-4 mîlyon MPS ve girêdayî ne, li gorî asta torê.
Ger hûn piçekî li ser pirsgirêkê bifikirin û di heman demê de berfê bi kepçeyê bikolin, dibe ku ev ramana eşkere ya jêrîn were bîra we: hûn hewceyê statsdek ku dikare di moda belavkirî de bixebite. Ango, yê ku hevdemkirinê di navbera girêkên dem û metrikan de pêk tîne. "Bê guman, çareseriyek wusa dibe ku jixwe hebe," me got û çû Google…. Û wan tiştek nedît. Piştî derbasbûna belgeyên ji bo statsd cuda ( ji 11.12.2017ê Kanûna Pêşîn, XNUMX), me bi tevahî tiştek nedît. Xuya ye, ne pêşdebiran û ne jî bikarhênerên van çareseriyan hîna bi ew çend metrîkan re rûbirû nebûn, wekî din ew ê bê guman tiştek derxin holê.
Û dûv re me statsd "lîstik" - bioyino, ya ku di hackathon Just for Fun de hatî nivîsandin hate bîra me (navê projeyê berî destpêkirina hackathonê ji hêla senaryoyê ve hatî çêkirin) û fêm kir ku em bi lez hewcedarê statsd-ya xwe ne. Bo çi?
- ji ber ku li cîhanê klona statsd pir hindik in,
- ji ber ku gengaz e ku meriv tolerans û mezinbûna xeletiya xwestî an nêzîkê peyda bike (tevî hevdengkirina metrîkên berhevkirî di navbera serveran de û çareserkirina pirsgirêka şandina nakokîyan),
- ji ber ku mimkun e ku meriv metrîkan rasttir ji brubeck hesab bike,
- ji ber ku hûn dikarin bi xwe statîstîkên berfirehtir berhev bikin, ku brubeck di pratîkê de ji me re nedaye,
- ji ber ku min şansek hebû ku ez hîperperformansa xwe ya belavbûyîscalelabplication bername bikim, ku dê mîmariya hîperforek din a din bi tevahî dubare neke... baş e, ew e.
Li ser çi binivîsin? Bê guman, li Rust. Çima?
- ji ber ku jixwe çareseriyek prototîp hebû,
- ji ber ku nivîskarê gotarê jixwe Rust di wê demê de nas dikir û dilxwaz bû ku di wê de tiştek ji bo hilberînê binivîsîne û bi derfeta ku wê di çavkaniya vekirî de binivîsîne,
- ji ber ku zimanên bi GC ji ber cewhera seyrûsefera hatî wergirtin (hema rast di wextê de) ji me re ne guncan in û rawestgehên GC bi pratîkî nayên pejirandin,
- ji ber ku hûn hewceyê performansa herî zêde ya ku bi C-yê ve tê berhev kirin hewce dike
- ji ber ku Rust hevdemiyek bê tirs ji me re peyda dike, û ger me dest bi nivîsandina wê bi C/C++ bikira, me ê ji xeynî brubeck hê bêtir qelsî, zêdebûna tampon, şert û mercên nijadê û gotinên din ên tirsnak bikira.
Li dijî Rust jî nîqaşek hebû. Pargîdanî çu ezmûna çêkirina projeyan li Rust nebû, û naha jî em plan nakin ku wê di projeya sereke de bikar bînin. Ji ber vê yekê, tirsên cidî hebûn ku tiştek biser nekeve, lê me biryar da ku em şansek bigirin û me hewl da.
Dem derbas bû...
Di dawiyê de, piştî çend hewildanên têkçûyî, yekem guhertoya xebatê amade bû. Çi qewimî? Ya ku qewimî ev e.
Her girêk komek metrîkên xwe distîne û wan berhev dike, û metrikan ji bo wan celebên ku tevheviya wan ji bo berhevkirina dawîn hewce ye berhev nake. Nod bi cûreyek protokola kilîtkirî ya belavkirî ve bi hevûdu ve têne girêdan, ku dihêle hûn di nav wan de yekane hilbijêrin (li vir em giriyan) ku hêja ye ku metrîkan bişîne Yekê Mezin. Ev pirsgirêk niha ji aliyê , lê di paşerojê de azweriyên nivîskar berbi Raft, ku yê herî hêja, bê guman, dê bibe xala serokê lihevhatinê. Digel lihevhatinê, girêk pir caran (ji hêla xwerû di çirkekê de carekê) wan beşên metrîkên pêş-komkirî yên ku wan di wê saniyeyê de berhev kirine ji cîranên xwe re dişînin. Derket holê ku pîvandin û tolerasyona xeletiyê têne parastin - her girêk hîn jî komek tevahî metrîkan digire, lê metrîk berê têne berhev kirin, bi riya TCP-ê ve têne şandin û di protokolek binary de têne kod kirin, ji ber vê yekê lêçûnên dubarekirinê li gorî UDP-ê bi girîngî kêm dibin. Tevî hejmareke pir mezin a metrîkên hatinê, berhevkirin pêdivî bi bîranîna pir hindik û hêj kêmtir CPU hewce dike. Ji bo mertîkên me yên pir bihevhatî, ev tenê çend deh megabyte daneyan e. Wekî bonusek din, em di Graphite de ji nû ve nivîsandina daneya nepêwist nagirin, wekî ku di derheqê burbeck de bû.
Pakêtên UDP yên bi metrîkan di navbera girêkên li ser alavên torê de bi navgînek Round Robin a hêsan de bêhevseng in. Bê guman, nermalava torê naveroka pakêtan pars nake û ji ber vê yekê dikare di çirkeyê de ji 4M pakêtan pirtir bikişîne, ne ku behsa metrîkên ku ew qet tiştek nizane. Ger em bihesibînin ku metrîk di her pakêtê de yek carî nayên, wê hingê em li vê deverê ti pirsgirêkên performansê pêşbînî nakin. Ger serverek têk bibe, cîhaza torê zû (di nav 1-2 çirkeyan de) vê rastiyê dibîne û servera têkçûyî ji zivirandinê derdixe. Wekî encamek vê yekê, girêkên pasîf (ango, ne-serok) dikarin bi pratîkî bêyî ku guheztinên li ser nexşeyan werin girtin û jêbirin. Herî zêde ya ku em winda dikin beşek ji metrîkên ku di saniyeya paşîn de ketine ye. Windabûn / girtin / guheztina rêberek ji nişka ve dê dîsa jî anomalîyek piçûk biafirîne (navbera 30 duyemîn hîn jî ji hevdeng e), lê heke di navbera girêkan de pêwendiyek hebe, ev pirsgirêk dikarin kêm bibin, mînakî, bi şandina pakêtên hevdemkirinê. .
Hinekî li ser avahiya navxweyî. Serlêdan, bê guman, pir-threaded e, lê mîmariya threading ji ya ku di brubeck de tê bikar anîn cûda ye. Mijarên di brubeck de yek in - her yek ji wan hem ji berhevkirina agahdarî û hem jî ji berhevkirinê berpirsiyar e. Di bioyino de, karker li du koman têne dabeş kirin: berpirsiyarên torê û yên ku ji berhevkirinê berpirsiyar in. Vê dabeşkirinê dihêle hûn li gorî celebê metrîkan serîlêdanê bi nermî rêve bibin: li cîhê ku berhevkirina zexm hewce ye, hûn dikarin berhevkaran lê zêde bikin, li cîhê ku seyrûsefera torê pir hebe, hûn dikarin hejmara herikîna torê lê zêde bikin. Heya nuha, li ser serverên me em di 8 torê û 4 herikîna kombûnê de dixebitin.
Beşa hejmartinê (berpirsiyarê kombûnê) pir bêzar e. Tamponên ku ji hêla herikîna torê ve têne dagirtin, di nav herikên hejmartinê de têne belav kirin, li wir ew paşê têne pars kirin û berhev kirin. Li ser daxwazê, metrîkên ji bo şandina girêkên din têne dayîn. Hemî ev, tevî şandina daneyan di navbera girêkan û xebata bi Konsulê re, bi asynchronously pêk tê, li ser çarçoveyê dixebite. .
Di dema pêşkeftinê de pir zêde pirsgirêk ji hêla beşa torê ya ku berpirsiyarê wergirtina metrîkan e ve hatî çêkirin. Armanca sereke ya veqetandina herikîna torê di nav dezgehên cihêreng de xwestina kêmkirina dema ku herikek derbas dike bû. ne ji bo xwendina daneyên ji soketê. Vebijarkên ku UDP-ya asynkron û recvmsg-ya birêkûpêk bikar tînin zû winda bûn: ya yekem ji bo pêvajoyek bûyerê CPU-ya cîhê bikarhêner pir zêde dixwe, ya duyemîn pir guheztinên kontekstê hewce dike. Ji ber vê yekê niha tê bikaranîn bi tamponên mezin (û tampon, birêz efser, ji we re ne tiştek in!). Piştgiriya UDP-ya birêkûpêk ji bo dozên sivik ên ku recvmmsg ne hewce ye ve hatî veqetandin. Di moda pir-mesajê de, gengaz e ku meriv bigihîje tiştê sereke: pirê caran, tîra torê rêza OS-ê radike - daneyên ji soketê dixwîne û vediguhezîne tampona cîhê bikarhêner, tenê carinan diguhezîne ku tampona dagirtî bide aggregators. Di soketê de rêza bi pratîkî nayê berhev kirin, hejmara pakêtên daketî bi pratîkî mezin nabe.
bingotin
Di mîhengên xwerû de, mezinahiya tampon tê destnîşan kirin ku pir mezin be. Ger hûn ji nişkê ve biryar bidin ku hûn serverê bixwe biceribînin, dibe ku hûn bi vê rastiyê re rû bi rû bimînin ku piştî şandina hejmarek piçûk metrîkan, ew ê negihin Graphite, di tampona tîrêja torê de bimînin. Ji bo ku hûn bi hejmareke piçûk a metrikan re bixebitin, hûn hewce ne ku di mîhengê de pîvana bufsize û peywir-dorê-mezinbûnê li nirxên piçûktir bicîh bikin.
Di dawiyê de, hin nexşe ji bo evîndarên nexşeyê.
Statîstîkên li ser hejmara metrîkên hatina ji bo her serverê: zêdetirî 2 mîlyon MPS.
Neçalakkirina yek ji girêkan û ji nû ve belavkirina metrîkên hatin.
Statîstîkên li ser metrîkên derketinê: tenê yek nod her gav dişîne - serokê raid.
Statîstîkên xebata her girêk, di modulên pergalê yên cihêreng de xeletiyan digirin.
Berfirehkirina metrîkên hatinê (navên metrîk veşartî ne).
Em ê bi van hemûyan paşerojê çi bikin? Bê guman, kodê binivîse, lanet...! Proje di destpêkê de hate plan kirin ku çavkaniya vekirî be û dê di tevahiya jiyana xwe de bimîne. Planên meyên tavilê veguheztina guhertoya xweya Raft, guheztina protokola peer li yekî portabletir, danasîna statîstîkên hundurîn ên zêde, celebên nû yên metrîkan, rastkirinên xeletiyan û çêtirkirinên din hene.
Bê guman, her kes bi xêr hatî ku di pêşveçûna projeyê de bibe alîkar: PR, Pirsgirêkan biafirînin, heke gengaz be em ê bersivê bidin, çêtir bikin, hwd.
Bi vê gotinê re, ev hemû gelî, fîlên me bikirin!
Source: www.habr.com