Zabbix ir uzraudzÄ«bas sistÄma. TÄpat kÄ jebkura cita sistÄma, tai ir trÄ«s galvenÄs visu uzraudzÄ«bas sistÄmu problÄmas: datu vÄkÅ”ana un apstrÄde, vÄstures saglabÄÅ”ana un tÄ«rÄ«Å”ana.
Datu saÅemÅ”anas, apstrÄdes un ierakstÄ«Å”anas posmi prasa laiku. Nav daudz, taÄu lielai sistÄmai tas var izraisÄ«t lielu kavÄÅ”anos. KrÄtuves problÄma ir datu piekļuves problÄma. Tos izmanto atskaitÄm, pÄrbaudÄm un aktivizÄtÄjiem. Datu piekļuves kavÄÅ”anÄs arÄ« ietekmÄ veiktspÄju. Kad datu bÄzes attÄ«stÄs, nebÅ«tiski dati ir jÄdzÄÅ”. NoÅemÅ”ana ir sarežģīta darbÄ«ba, kas arÄ« patÄrÄ dažus resursus.
Aizkaves problÄmas savÄkÅ”anas un uzglabÄÅ”anas laikÄ Zabbix tiek atrisinÄtas ar keÅ”atmiÅu: vairÄku veidu keÅ”atmiÅas, keÅ”atmiÅa datu bÄzÄ. Lai atrisinÄtu treÅ”o problÄmu, keÅ”atmiÅa nav piemÄrota, tÄpÄc Zabbix izmantoja TimescaleDB. ViÅÅ” jums par to pastÄstÄ«s Andrejs GuÅ”Äins - tehniskÄ atbalsta inženieris . Andrejs atbalsta Zabbix vairÄk nekÄ 6 gadus, un viÅam ir tieÅ”a pieredze ar sniegumu.
KÄ darbojas TimescaleDB, kÄdu veiktspÄju tas var nodroÅ”inÄt salÄ«dzinÄjumÄ ar parasto PostgreSQL? KÄdu lomu Zabbix spÄlÄ TimescaleDB datubÄzÄ? KÄ sÄkt no nulles un kÄ migrÄt no PostgreSQL un kurai konfigurÄcijai ir labÄka veiktspÄja? Par to visu zem griezuma.
ProduktivitÄtes izaicinÄjumi
Katra uzraudzÄ«bas sistÄma saskaras ar Ä«paÅ”Äm veiktspÄjas problÄmÄm. Es runÄÅ”u par trim no tiem: datu vÄkÅ”anu un apstrÄdi, glabÄÅ”anu un vÄstures notÄ«rÄ«Å”anu.
Ätra datu vÄkÅ”ana un apstrÄde. Labai uzraudzÄ«bas sistÄmai Ätri jÄsaÅem visi dati un jÄapstrÄdÄ tie atbilstoÅ”i trigera izteiksmÄm ā atbilstoÅ”i tÄs kritÄrijiem. PÄc apstrÄdes sistÄmai Å”ie dati arÄ« Ätri jÄsaglabÄ datu bÄzÄ vÄlÄkai lietoÅ”anai.
VÄstures glabÄÅ”ana. Labai uzraudzÄ«bas sistÄmai vÄsture jÄsaglabÄ datu bÄzÄ un jÄnodroÅ”ina viegla piekļuve metrikÄm. VÄsture ir nepiecieÅ”ama, lai to izmantotu pÄrskatos, diagrammÄs, aktivizÄtÄjos, sliekÅ”Åos un aprÄÄ·inÄtajos brÄ«dinÄjumu datu vienumos.
VÄstures dzÄÅ”ana. Dažreiz pienÄk diena, kad nav nepiecieÅ”ams uzglabÄt rÄdÄ«tÄjus. KÄpÄc jums ir nepiecieÅ”ami dati, kas apkopoti pirms 5 gadiem, mÄnesi vai diviem: daži mezgli ir izdzÄsti, daži saimniekdatori vai metrika vairs nav nepiecieÅ”ami, jo tie ir novecojuÅ”i un vairs netiek apkopoti. Labai uzraudzÄ«bas sistÄmai vajadzÄtu saglabÄt vÄsturiskos datus un laiku pa laikam tos dzÄst, lai datubÄze neaug.
NovecojuÅ”u datu tÄ«rÄ«Å”ana ir kritiska problÄma, kas lielÄ mÄrÄ ietekmÄ datu bÄzes veiktspÄju.
KeÅ”atmiÅa Zabbix
ProgrammÄ Zabbix pirmais un otrais zvans tiek atrisinÄts, izmantojot keÅ”atmiÅu. RAM tiek izmantota datu vÄkÅ”anai un apstrÄdei. UzglabÄÅ”anai - vÄsture trigeros, grafikos un aprÄÄ·inÄtajos datu elementos. DatubÄzes pusÄ ir keÅ”atmiÅa pamata atlasÄm, piemÄram, grafikiem.
KeÅ”atmiÅa paÅ”Ä Zabbix servera pusÄ ir:
- KonfigurÄcijas keÅ”atmiÅa;
- ValueCache;
- HistoryCache;
- TrendsCache.
Apsveriet tos sÄ«kÄk.
KonfigurÄcijas keÅ”atmiÅa
Å Ä« ir galvenÄ keÅ”atmiÅa, kurÄ mÄs glabÄjam metriku, saimniekdatorus, datu vienumus, trigerus ā visu, kas nepiecieÅ”ams pirmapstrÄdei un datu apkopoÅ”anai.
Tas viss tiek saglabÄts ConfigurationCache, lai datu bÄzÄ neradÄ«tu nevajadzÄ«gus vaicÄjumus. PÄc servera palaiÅ”anas mÄs atjauninÄm Å”o keÅ”atmiÅu, izveidojam un periodiski atjauninÄm konfigurÄcijas.
Datu vÄkÅ”ana
Diagramma ir diezgan liela, bet galvenais tajÄ ir kolekcionÄri. Tie ir dažÄdi āpolleriā ā montÄžas procesi. ViÅi ir atbildÄ«gi par dažÄda veida montÄžu: vÄc datus, izmantojot SNMP, IPMI, un pÄrsÅ«ta to visu uz PreProcessing.
Kolektori ir iezÄ«mÄti oranÅ¾Ä krÄsÄ.
Zabbix ir aprÄÄ·inÄjis apkopojuma vienumus, kas nepiecieÅ”ami, lai apkopotu pÄrbaudes. Ja mums tie ir, mÄs iegÅ«stam to datus tieÅ”i no ValueCache.
PirmsapstrÄdes vÄstures keÅ”atmiÅa
Visi kolekcionÄri darbu saÅemÅ”anai izmanto ConfigurationCache. PÄc tam viÅi tos pÄrsÅ«ta uz PreProcessing.
PriekÅ”apstrÄde izmanto ConfigurationCache, lai saÅemtu priekÅ”apstrÄdes darbÄ«bas. TÄ apstrÄdÄ Å”os datus dažÄdos veidos.
PÄc datu apstrÄdes, izmantojot priekÅ”apstrÄdi, mÄs tos saglabÄjam apstrÄdei HistoryCache. Tas beidz datu vÄkÅ”anu, un mÄs pÄrejam pie galvenÄ procesa Zabbix - vÄstures sinhronizators, jo tÄ ir monolÄ«ta arhitektÅ«ra.
PiezÄ«me. IepriekÅ”Äja apstrÄde ir diezgan sarežģīta darbÄ«ba. Izmantojot versiju 4.2, tas ir pÄrvietots uz starpniekserveri. Ja jums ir ļoti liels Zabbix ar lielu datu elementu skaitu un vÄkÅ”anas biežumu, tas ievÄrojami atvieglo darbu.
ValueCache, vÄstures un tendenÄu keÅ”atmiÅa
VÄstures sinhronizators ir galvenais process, kas atomiski apstrÄdÄ katru datu elementu, tas ir, katru vÄrtÄ«bu.
VÄstures sinhronizators Åem vÄrtÄ«bas no vÄstures keÅ”atmiÅas un pÄrbauda konfigurÄciju, vai nav aprÄÄ·inu aktivizÄtÄju. Ja tie pastÄv, tas aprÄÄ·ina.
VÄstures sinhronizÄtÄjs izveido notikumu, eskalÄciju, lai izveidotu brÄ«dinÄjumus, ja to pieprasa konfigurÄcija, un ierakstus. Ja ir aktivizÄtÄji turpmÄkai apstrÄdei, tÄ saglabÄ Å”o vÄrtÄ«bu keÅ”atmiÅÄ ValueCache, lai nepiekļūtu vÄstures tabulai. Å Ädi ValueCache tiek aizpildÄ«ta ar datiem, kas nepiecieÅ”ami trigeru un aprÄÄ·inÄto elementu aprÄÄ·inÄÅ”anai.
VÄstures sinhronizators ieraksta visus datus datu bÄzÄ, un tas ieraksta diskÄ. ApstrÄdes process beidzas Å”eit.
KeÅ”atmiÅas saglabÄÅ”ana datu bÄzÄ
Datu bÄzes pusÄ ir dažÄdas keÅ”atmiÅas, kad vÄlaties skatÄ«t grafikus vai pÄrskatus par notikumiem:
Innodb_buffer_poolMySQL pusÄ;shared_buffersPostgreSQL pusÄ;effective_cache_sizeOracle pusÄ;shared_poolDB2 pusÄ.
Ir daudzas citas keÅ”atmiÅas, taÄu tÄs ir galvenÄs visÄm datu bÄzÄm. Tie ļauj saglabÄt datus RAM, kas bieži ir nepiecieÅ”ami vaicÄjumiem. ViÅiem ir savas tehnoloÄ£ijas Å”im nolÅ«kam.
Datu bÄzes veiktspÄja ir kritiska
Zabbix serveris pastÄvÄ«gi vÄc datus un raksta tos. RestartÄjot, tas arÄ« tiek nolasÄ«ts no vÄstures, lai aizpildÄ«tu ValueCache. Izmanto skriptus un atskaites Zabbix API, kas ir veidota uz tÄ«mekļa saskarnes. Zabbix API piekļūst datu bÄzei un izgÅ«st nepiecieÅ”amos datus grafikiem, atskaitÄm, notikumu sarakstiem un jaunÄkajÄm problÄmÄm.
VizualizÄcijai - grafana. Å is ir populÄrs risinÄjums mÅ«su lietotÄju vidÅ«. Tas var tieÅ”i nosÅ«tÄ«t pieprasÄ«jumus, izmantojot Zabbix API un datu bÄzi, un rada zinÄmu konkurenci datu saÅemÅ”anai. TÄpÄc ir nepiecieÅ”ama precÄ«zÄka un labÄka datubÄze, lai tÄ atbilstu Ätrai rezultÄtu piegÄdei un testÄÅ”anai.
Saimniece
TreÅ”ais Zabbix veiktspÄjas izaicinÄjums ir vÄstures tÄ«rÄ«Å”ana, izmantojot Housekeeper. Tas seko visiem uzstÄdÄ«jumiem ā datu elementi norÄda, cik ilgi jÄuzglabÄ izmaiÅu (tendenÄu) dinamika dienÄs.
MÄs aprÄÄ·inÄm TrendsCache lidojumÄ. Kad dati tiek saÅemti, mÄs tos apkopojam vienu stundu un ierakstÄm tabulÄs tendenÄu izmaiÅu dinamikai.
MÄjkalpotÄjs sÄk un dzÄÅ” informÄciju no datu bÄzes, izmantojot parastos āatlasÄ«jumusā. Tas ne vienmÄr ir efektÄ«vs, kÄ redzams iekÅ”Äjo procesu veiktspÄjas diagrammÄs.
SarkanajÄ diagrammÄ redzams, ka vÄstures sinhronizators ir pastÄvÄ«gi aizÅemts. AugÅ”pusÄ oranÅ¾Ä diagramma ir Housekeeper, kas pastÄvÄ«gi darbojas. ViÅÅ” gaida, lÄ«dz datu bÄze izdzÄsÄ«s visas viÅa norÄdÄ«tÄs rindas.
Kad vajadzÄtu atspÄjot Housekeeper? PiemÄram, ir āPreces IDā, un jums ir jÄizdzÄÅ” pÄdÄjÄs 5 XNUMX rindu noteiktÄ laikÄ. Protams, tas notiek pÄc indeksa. Bet parasti datu kopa ir ļoti liela, un datu bÄze joprojÄm nolasa no diska un ievieto to keÅ”atmiÅÄ. TÄ vienmÄr ir ļoti dÄrga datubÄzes darbÄ«ba un atkarÄ«bÄ no datu bÄzes lieluma var izraisÄ«t veiktspÄjas problÄmas.
ApkopÄja ir viegli atspÄjojama. TÄ«mekļa saskarnÄ ir iestatÄ«jums "VispÄrÄ«ga administrÄÅ”ana" mÄjkalpotÄjai. MÄs atspÄjojam iekÅ”Äjo mÄjturÄ«bu iekÅ”Äjo tendenÄu vÄsturei, un tÄ vairs to nepÄrvalda.
MÄjsaimniece tika izslÄgta, grafiki izlÄ«dzinÄjÄs - kÄdas problÄmas Å”ajÄ gadÄ«jumÄ varÄtu bÅ«t un kas varÄtu palÄ«dzÄt atrisinÄt treÅ”o izpildÄ«juma izaicinÄjumu?
SadalīŔana - sadalīŔana vai sadalīŔana
Parasti sadalÄ«Å”ana katrÄ uzskaitÄ«tajÄ relÄciju datu bÄzÄ tiek konfigurÄta atŔķirÄ«gÄ veidÄ. Katrai no tÄm ir sava tehnoloÄ£ija, taÄu kopumÄ tÄs ir lÄ«dzÄ«gas. Jauna nodalÄ«juma izveide bieži rada noteiktas problÄmas.
Parasti nodalÄ«jumi tiek konfigurÄti atkarÄ«bÄ no āiestatÄ«Å”anasā - datu apjoma, kas tiek izveidots vienÄ dienÄ. Parasti sadalÄ«Å”ana tiek izdota vienÄ dienÄ, tas ir minimums. Jaunas partijas tendencÄm - 1 mÄnesis.
VÄrtÄ«bas var mainÄ«ties, ja āiestatÄ«jumsā ir ļoti liels. Ja mazs āiestatÄ«jumsā ir lÄ«dz 5 nvps (jaunas vÄrtÄ«bas sekundÄ), vidÄjais ir no 000 lÄ«dz 5 000, tad lielais ir virs 25 000 nvps. TÄs ir lielas un ļoti lielas instalÄcijas, kurÄm nepiecieÅ”ama rÅ«pÄ«ga datu bÄzes konfigurÄÅ”ana.
Ä»oti lielÄm iekÄrtÄm vienas dienas periods var nebÅ«t optimÄls. Esmu redzÄjis MySQL nodalÄ«jumus ar 40 GB vai vairÄk dienÄ. Tas ir ļoti liels datu apjoms, kas var radÄ«t problÄmas un kas ir jÄsamazina.
Ko dod sadalīŔana?
SadalÄ«Å”anas tabulas. Bieži vien tie ir atseviŔķi faili diskÄ. VaicÄjumu plÄns optimÄlÄk atlasa vienu nodalÄ«jumu. Parasti sadalÄ«Å”anu izmanto diapazonÄ ā tas attiecas arÄ« uz Zabbix. MÄs tur lietojam ālaikspiedoluā ā laiku kopÅ” laikmeta sÄkuma. Tie mums ir parastie skaitļi. JÅ«s iestatÄt dienas sÄkumu un beigas - tas ir nodalÄ«jums.
Ätra noÅemÅ”ana SÄkot no DELETE. Tiek atlasÄ«ts viens fails/apakÅ”tabula, nevis rindu atlase dzÄÅ”anai.
IevÄrojami paÄtrina datu izgÅ«Å”anu SELECT - izmanto vienu vai vairÄkus nodalÄ«jumus, nevis visu tabulu. Ja piekļūstat datiem, kas ir divas dienas veci, tie tiek izgÅ«ti no datu bÄzes ÄtrÄk, jo keÅ”atmiÅÄ ir jÄielÄdÄ tikai viens fails un tas jÄatgriež, nevis liela tabula.
Bieži vien daudzas datu bÄzes tiek arÄ« paÄtrinÄtas INSERT ā ievietojumi bÄrnu tabulÄ.
TermiÅÅ”DB
Versijai 4.2 mÄs pievÄrsÄm uzmanÄ«bu TimescaleDB. Å is ir PostgreSQL paplaÅ”inÄjums ar vietÄjo saskarni. PaplaÅ”inÄjums efektÄ«vi darbojas ar laikrindu datiem, nezaudÄjot relÄciju datu bÄzu priekÅ”rocÄ«bas. TimescaleDB arÄ« automÄtiski sadalÄs.
TimescaleDB ir koncepcija hipertable (hipertable), ko izveidojat. Tas satur gabalos - starpsienas. Gabali ir automÄtiski pÄrvaldÄ«ti hipertabulu fragmenti, kas neietekmÄ citus fragmentus. Katrai daļai ir savs laika diapazons.
TimescaleDB vs PostgreSQL
TimescaleDB darbojas patieÅ”Äm efektÄ«vi. PaplaÅ”inÄjuma ražotÄji apgalvo, ka izmanto pareizÄku vaicÄjumu apstrÄdes algoritmu, jo Ä«paÅ”i inserts . Pieaugot datu kopas ievietoÅ”anas lielumam, algoritms uztur nemainÄ«gu veiktspÄju.
PÄc 200 miljoniem rindu PostgreSQL parasti sÄk ievÄrojami samazinÄties un zaudÄ veiktspÄju lÄ«dz 0. TimescaleDB ļauj efektÄ«vi ievietot āievietojumusā jebkuram datu apjomam.
UzstÄdÄ«Å”ana
TimescaleDB instalÄÅ”ana jebkurai pakotnei ir diezgan vienkÄrÅ”a. IN viss ir sÄ«ki aprakstÄ«ts - tas ir atkarÄ«gs no oficiÄlajÄm PostgreSQL pakotnÄm. TimescaleDB var arÄ« izveidot un apkopot manuÄli.
Zabbix datu bÄzei mÄs vienkÄrÅ”i aktivizÄjam paplaÅ”inÄjumu:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
JÅ«s aktivizÄjat extension un izveidojiet to Zabbix datubÄzei. PÄdÄjais solis ir izveidot hipertabulu.
VÄstures tabulu migrÄÅ”ana uz TimescaleDB
Tam ir īpaŔa funkcija create_hypertable:
SELECT create_hypertable(āhistoryā, āclockā, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(āhistory_unitā, āclockā, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(āhistory_logā, āclockā, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(āhistory_textā, āclockā, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(āhistory_strā, āclockā, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(ātrendsā, āclockā, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(ātrends_unitā, āclockā, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=ātimescaledbā, hk_history_global=1, hk_trends_global=1
Funkcijai ir trÄ«s parametri. PirmkÄrt - tabula datu bÄzÄ, kam jÄizveido hipertabula. Otrais - laukÄ, saskaÅÄ ar kuru jums ir jÄizveido chunk_time_interval ā izmantojamo nodalÄ«jumu daļu intervÄls. ManÄ gadÄ«jumÄ intervÄls ir viena diena - 86 400.
TreÅ”ais parametrs - migrate_data. Ja iestatÄt true, tad visi paÅ”reizÄjie dati tiek pÄrsÅ«tÄ«ti uz iepriekÅ” izveidotiem gabaliem. Pats izmantoju migrate_data. Man bija apmÄram 1 TB, kas ilga vairÄk nekÄ stundu. Pat dažos gadÄ«jumos testÄÅ”anas laikÄ es izdzÄsu vÄsturiskos datus par rakstzÄ«mju veidiem, kas nebija nepiecieÅ”ami glabÄÅ”anai, lai tos nepÄrsÅ«tÄ«tu.
PÄdÄjais solis - UPDATE: plkst db_extension ielieciet timescaledblai datu bÄze saprastu, ka Å”is paplaÅ”inÄjums pastÄv. Zabbix to aktivizÄ un pareizi izmanto datu bÄzes sintaksi un vaicÄjumus - tÄs funkcijas, kas ir nepiecieÅ”amas TimescaleDB.
AparatÅ«ras konfigurÄcija
Es izmantoju divus serverus. PirmkÄrt - VMware maŔīna. Tas ir diezgan mazs: 20 IntelĀ® XeonĀ® CPU E5-2630 v 4 @ 2.20 GHz procesori, 16 GB RAM un 200 GB SSD.
Es tajÄ instalÄju PostgreSQL 10.8 ar Debian 10.8-1.pgdg90+1 OS un xfs failu sistÄmu. Es visu konfigurÄju minimÄli, lai izmantotu Å”o konkrÄto datu bÄzi, atskaitot to, ko izmantos pats Zabbix.
TajÄ paÅ”Ä maŔīnÄ bija Zabbix serveris, PostgreSQL un kravas aÄ£enti. Man bija 50 aktÄ«vÄs vielas, kuras lietoju LoadableModulelai ļoti Ätri Ä£enerÄtu dažÄdus rezultÄtus: skaitļus, virknes. Es aizpildÄ«ju datubÄzi ar daudziem datiem.
SÄkotnÄji ietvertÄ konfigurÄcija 5 elementu dati uz vienu saimniekdatoru. GandrÄ«z katrs elements saturÄja sprÅ«da, lai padarÄ«tu to lÄ«dzÄ«gu Ä«stÄm instalÄcijÄm. Dažos gadÄ«jumos bija vairÄk nekÄ viens sprÅ«da. Vienam tÄ«kla mezglam bija 3ā000 aktivizÄtÄju.
Datu vienumu atjauninÄÅ”anas intervÄls - 4-7 sekundes. PaÅ”u slodzi regulÄju, izmantojot ne tikai 50 lÄ«dzekļus, bet pievienojot vÄl. TÄpat, izmantojot datu elementus, dinamiski noregulÄju slodzi un samazinÄju atjauninÄÅ”anas intervÄlu lÄ«dz 4 s.
PostgreSQL. 35 000 nvps
Mans pirmais darbs ar Å”o aparatÅ«ru bija tÄ«rÄ PostgreSQL ā 35 tÅ«kstoÅ”i vÄrtÄ«bu sekundÄ. KÄ redzat, datu ievietoÅ”ana aizÅem sekundes daļas - viss ir labi un Ätri. VienÄ«gais, ka 200 GB SSD disks Ätri piepildÄs.
Å is ir standarta Zabbix servera veiktspÄjas informÄcijas panelis.
Pirmais zilais grafiks ir vÄrtÄ«bu skaits sekundÄ. Otrais grafiks labajÄ pusÄ ir veidoÅ”anas procesu ielÄde. TreÅ”ais ir iekÅ”Äjo bÅ«vÄÅ”anas procesu ielÄde: vÄstures sinhronizatori un Housekeeper, kas Å”eit darbojas jau labu laiku.
CeturtajÄ diagrammÄ parÄdÄ«ts HistoryCache lietojums. Tas ir sava veida buferis pirms ievietoÅ”anas datu bÄzÄ. ZaļajÄ piektajÄ diagrammÄ parÄdÄ«ts ValueCache lietojums, tas ir, cik ValueCache trÄpÄ«jumu aktivizÄtÄjiem ā tas ir vairÄki tÅ«kstoÅ”i vÄrtÄ«bu sekundÄ.
PostgreSQL. 50 000 nvps
Tad es palielinÄju slodzi lÄ«dz 50 tÅ«kstoÅ”iem vÄrtÄ«bu sekundÄ tajÄ paÅ”Ä aparatÅ«rÄ.
IelÄdÄjot no Housekeeper, 10 tÅ«kstoÅ”u vÄrtÄ«bu ievietoÅ”ana aizÅÄma 2-3 sekundes.
MÄjkalpotÄja jau sÄk traucÄt darbu.
TreÅ”ajÄ grafikÄ redzams, ka kopumÄ traperu un vÄstures sinhronotÄju slodze joprojÄm ir 60%. CeturtajÄ grafikÄ Housekeeper darbÄ«bas laikÄ HistoryCache jau sÄk diezgan aktÄ«vi pildÄ«ties. Tas ir 20% pilns, kas ir aptuveni 0,5 GB.
PostgreSQL. 80 000 nvps
Tad es palielinÄju slodzi lÄ«dz 80 tÅ«kstoÅ”iem vÄrtÄ«bu sekundÄ. Tas ir aptuveni 400 tÅ«kstoÅ”i datu elementu un 280 tÅ«kstoÅ”i aktivizÄtÄju.
TrÄ«sdesmit vÄstures sinhronizÄtÄju ielÄdes izmaksas jau ir diezgan augstas.
PalielinÄju arÄ« dažÄdus parametrus: vÄstures sinhronizÄcijas, keÅ”atmiÅas.
ManÄ aparatÅ«rÄ vÄstures sinhronizatoru ielÄde palielinÄjÄs lÄ«dz maksimumam. HistoryCache Ätri piepildÄ«jÄs ar datiem - buferÄ« bija uzkrÄjuÅ”ies dati apstrÄdei.
Visu Å”o laiku novÄroju, kÄ tiek izmantots procesors, operatÄ«vÄ atmiÅa un citi sistÄmas parametri, un konstatÄju, ka diska noslodze ir maksimÄla.
Esmu sasniedzis izmantoÅ”anu maksimÄlÄs diska iespÄjas Å”ajÄ aparatÅ«rÄ un Å”ajÄ virtuÄlajÄ maŔīnÄ. Ar Å”Ädu intensitÄti PostgreSQL sÄka diezgan aktÄ«vi izskalot datus, un diskam vairs nebija laika rakstÄ«t un lasÄ«t.
Otrais serveris
PaÅÄmu citu serveri, kurÄ jau bija 48 procesori un 128 GB RAM. Es to noregulÄju - iestatÄ«ju uz 60 vÄstures sinhronizÄciju un sasniedzu pieÅemamu veiktspÄju.
Faktiski tÄ jau ir produktivitÄtes robeža, kur kaut kas ir jÄdara.
TimescaleDB. 80 000 nvps
Mans galvenais uzdevums ir pÄrbaudÄ«t TimescaleDB iespÄjas pret Zabbix slodzi. 80 tÅ«kstoÅ”i vÄrtÄ«bu sekundÄ ir daudz, metrikas vÄkÅ”anas biežums (protams, izÅemot Yandex) un diezgan liels āiestatÄ«jumsā.
KatrÄ grafikÄ ir kritums ā tieÅ”i tÄ ir datu migrÄcija. PÄc kļūmÄm Zabbix serverÄ« vÄstures sinhronizÄtÄja ielÄdes profils ļoti mainÄ«jÄs - tas nokritÄs trÄ«s reizes.
TimescaleDB ļauj ievietot datus gandrÄ«z 3 reizes ÄtrÄk un izmantot mazÄk HistoryCache.
AttiecÄ«gi jÅ«s saÅemsiet datus savlaicÄ«gi.
TimescaleDB. 120 000 nvps
Tad es palielinÄju datu elementu skaitu lÄ«dz 500 tÅ«kstoÅ”iem. Galvenais uzdevums bija pÄrbaudÄ«t TimescaleDB iespÄjas - es saÅÄmu aprÄÄ·inÄto vÄrtÄ«bu 125 tÅ«kstoÅ”i vÄrtÄ«bu sekundÄ.
Å Ä« ir darba āiestatÄ«Å”anaā, kas var darboties ilgu laiku. Bet, tÄ kÄ mans disks bija tikai 1,5 TB, es to aizpildÄ«ju pÄris dienu laikÄ.
VissvarÄ«gÄkais ir tas, ka tajÄ paÅ”Ä laikÄ tika izveidoti jauni TimescaleDB nodalÄ«jumi.
Tas ir pilnÄ«gi nepamanÄms veiktspÄjai. PiemÄram, ja MySQL tiek izveidoti nodalÄ«jumi, viss ir savÄdÄk. Tas parasti notiek naktÄ«, jo tas bloÄ·Ä vispÄrÄju ievietoÅ”anu, darbu ar tabulÄm un var izraisÄ«t pakalpojuma degradÄciju. Tas neattiecas uz TimescaleDB.
KÄ piemÄru es parÄdÄ«Å”u vienu diagrammu no daudziem kopienÄ. AttÄlÄ ir iespÄjots TimescaleDB, pateicoties kuram ir samazinÄjusies slodze uz io.weight izmantoÅ”anu procesoram. SamazinÄjÄs arÄ« iekÅ”Äjo procesa elementu izmantoÅ”ana. TurklÄt Ŕī ir parasta virtuÄlÄ maŔīna uz parastajiem pankÅ«ku diskiem, nevis SSD.
Atzinumi
TimescaleDB ir labs risinÄjums nelielai "iestatÄ«Å”anai", kas ietekmÄ diska veiktspÄju. Tas ļaus jums turpinÄt strÄdÄt labi, lÄ«dz datu bÄze pÄc iespÄjas ÄtrÄk tiks migrÄta uz aparatÅ«ru.
TimescaleDB ir viegli konfigurÄjams, nodroÅ”ina veiktspÄjas pieaugumu, labi darbojas ar Zabbix un ir priekÅ”rocÄ«bas salÄ«dzinÄjumÄ ar PostgreSQL.
Ja izmantojat PostgreSQL un neplÄnojat to mainÄ«t, iesaku izmantojiet PostgreSQL ar paplaÅ”inÄjumu TimescaleDB kopÄ ar Zabbix. Å is risinÄjums darbojas efektÄ«vi lÄ«dz vidÄjai "iestatÄ«jumam".
Kad mÄs sakÄm āaugsta veiktspÄjaā, mÄs domÄjam . Jums nebÅ«s ilgi jÄgaida, lai uzzinÄtu par tehnoloÄ£ijÄm un praksi, kas ļauj pakalpojumiem apkalpot miljoniem lietotÄju. Saraksts 7. un 8. novembrim jau apkopojÄm, bet Å”eit var ieteikt vairÄk.
AbonÄjiet mÅ«su Šø , kurÄ atklÄjam gaidÄmÄs konferences iezÄ«mes un uzzinÄm, kÄ no tÄs gÅ«t maksimÄlu labumu.
Avots: www.habr.com