Byddwn yn edrych ar sut mae Zabbix yn gweithio gyda chronfa ddata TimescaleDB fel y pen ôl. Byddwn yn dangos i chi sut i ddechrau o'r dechrau a sut i fudo o PostgreSQL. Byddwn hefyd yn darparu profion perfformiad cymharol o'r ddau ffurfweddiad.
HighLoad++ Siberia 2019. Neuadd Tomsk. Mehefin 24, 16:00. traethodau ymchwil a . Cynhelir y gynhadledd HighLoad ++ nesaf ar Ebrill 6 a 7, 2020 yn St Petersburg. Manylion a thocynnau .
Andrey Gushchin (o hyn ymlaen - AG): - Rwy'n beiriannydd cymorth technegol ZABBIX (y cyfeirir ato o hyn ymlaen fel “Zabbix”), hyfforddwr. Rwyf wedi bod yn gweithio ym maes cymorth technegol am fwy na 6 mlynedd ac wedi cael profiad uniongyrchol gyda pherfformiad. Heddiw, byddaf yn siarad am y perfformiad y gall TimescaleDB ei ddarparu o'i gymharu â PostgreSQL 10 rheolaidd. Hefyd, rhywfaint o ran ragarweiniol am sut mae'n gweithio'n gyffredinol.
Prif heriau cynhyrchiant: o gasglu data i lanhau data
I ddechrau, mae heriau perfformiad penodol y mae pob system fonitro yn eu hwynebu. Yr her cynhyrchiant gyntaf yw casglu a phrosesu data yn gyflym.
Dylai system fonitro dda dderbyn yr holl ddata yn gyflym, yn amserol, ei brosesu yn unol â mynegiadau sbardun, hynny yw, ei brosesu yn unol â rhai meini prawf (mae hyn yn wahanol mewn gwahanol systemau) a'i gadw mewn cronfa ddata er mwyn defnyddio'r data hwn yn y dyfodol.
Yr ail her perfformiad yw storio hanes. Storio mewn cronfa ddata yn aml a chael mynediad cyflym a chyfleus i'r metrigau hyn a gasglwyd dros gyfnod o amser. Y peth pwysicaf yw bod y data hwn yn gyfleus i'w gael, ei ddefnyddio mewn adroddiadau, graffiau, sbardunau, mewn rhai gwerthoedd trothwy, ar gyfer rhybuddion, ac ati.
Y trydydd her perfformiad yw clirio hanes, hynny yw, pan fyddwch chi'n cyrraedd y pwynt lle nad oes angen i chi storio unrhyw fetrigau manwl sydd wedi'u casglu dros 5 mlynedd (hyd yn oed fisoedd neu ddau fis). Cafodd rhai nodau rhwydwaith eu dileu, neu rai gwesteiwyr, nid oes angen y metrigau mwyach oherwydd eu bod eisoes wedi dyddio ac nid ydynt yn cael eu casglu mwyach. Mae angen glanhau hyn i gyd fel nad yw'ch cronfa ddata yn tyfu'n rhy fawr. Yn gyffredinol, mae hanes clirio yn aml yn brawf difrifol ar gyfer storio - yn aml mae'n cael effaith gref iawn ar berfformiad.
Sut i ddatrys problemau caching?
Byddaf yn awr yn siarad yn benodol am Zabbix. Yn Zabbix, mae'r alwad gyntaf a'r ail alwad yn cael eu datrys gan ddefnyddio caching.
Casglu a phrosesu data - Rydym yn defnyddio RAM i storio'r holl ddata hwn. Bydd y data hyn yn cael eu trafod yn fanylach yn awr.
Hefyd ar ochr y gronfa ddata mae rhywfaint o caching ar gyfer y prif ddetholiadau - ar gyfer graffiau a phethau eraill.
Caching ar ochr y gweinydd Zabbix ei hun: mae gennym ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Beth yw e?
ConfigurationCache yw'r prif storfa lle rydym yn storio metrigau, gwesteiwyr, eitemau data, sbardunau; popeth sydd ei angen arnoch i brosesu rhagbrosesu, casglu data, gan ba westeion i'w casglu, pa mor aml. Mae hyn i gyd yn cael ei storio yn ConfigurationCache er mwyn peidio â mynd i'r gronfa ddata a chreu ymholiadau diangen. Ar ôl i'r gweinydd ddechrau, rydym yn diweddaru'r storfa hon (yn ei greu) ac yn ei ddiweddaru o bryd i'w gilydd (yn dibynnu ar y gosodiadau cyfluniad).
Caching yn Zabbix. Casglu data
Yma mae'r diagram yn eithaf mawr:
Y prif rai yn y cynllun yw'r casglwyr hyn:
Dyma'r prosesau cynulliad eu hunain, amrywiol “bolwyr” sy'n gyfrifol am wahanol fathau o gynulliadau. Maent yn casglu data trwy icmp, ipmi, a phrotocolau amrywiol ac yn trosglwyddo'r cyfan i ragbrosesu.
PreProcessing HistoryCache
Hefyd, os ydym wedi cyfrifo elfennau data (mae'r rhai sy'n gyfarwydd â Zabbix yn gwybod), hynny yw, wedi'i gyfrifo, elfennau data agregu, rydym yn eu cymryd yn uniongyrchol o ValueCache. Byddaf yn dweud wrthych sut y caiff ei lenwi yn nes ymlaen. Mae'r casglwyr hyn i gyd yn defnyddio ConfigurationCache i dderbyn eu swyddi ac yna'n eu trosglwyddo i ragbrosesu.
Mae Preprocessing hefyd yn defnyddio ConfigurationCache i gael camau rhagbrosesu a phrosesu'r data hwn mewn amrywiol ffyrdd. Gan ddechrau o fersiwn 4.2, rydym wedi ei symud i ddirprwy. Mae hyn yn gyfleus iawn, oherwydd mae rhagbrosesu ei hun yn weithrediad eithaf anodd. Ac os oes gennych chi Zabbix mawr iawn, gyda nifer fawr o elfennau data ac amlder casglu uchel, yna mae hyn yn symleiddio'r gwaith yn fawr.
Yn unol â hynny, ar ôl i ni brosesu'r data hwn mewn rhyw ffordd gan ddefnyddio rhagbrosesu, rydym yn ei gadw yn HistoryCache er mwyn ei brosesu ymhellach. Mae hyn yn dod â'r casgliad data i ben. Symudwn ymlaen at y brif broses.
Gwaith cysonwr hanes
Y brif broses yn Zabbix (gan mai pensaernïaeth monolithig ydyw) yw History syncer. Dyma'r brif broses sy'n delio'n benodol â phrosesu atomig pob elfen ddata, hynny yw, pob gwerth:
- daw'r gwerth (mae'n ei gymryd o HistoryCache);
- gwiriadau yn Configuration syncer: a oes unrhyw sbardunau ar gyfer cyfrifo - yn eu cyfrifo;
if there is - yn creu digwyddiadau, yn creu uwchgyfeirio er mwyn creu rhybudd, os oes angen yn ôl y ffurfwedd; - cofnodion sbardunau ar gyfer prosesu dilynol, agregu; os ydych chi'n agregu dros yr awr ddiwethaf ac yn y blaen, mae ValueCache yn cofio'r gwerth hwn er mwyn peidio â mynd i'r tabl hanes; Felly, mae'r ValueCache wedi'i lenwi â'r data angenrheidiol sy'n angenrheidiol i gyfrifo sbardunau, elfennau wedi'u cyfrifo, ac ati;
- yna mae History syncer yn ysgrifennu'r holl ddata i'r gronfa ddata;
- mae'r gronfa ddata yn eu hysgrifennu i ddisg - dyma lle mae'r broses brosesu yn dod i ben.
Cronfa Ddata. Caching
Ar ochr y gronfa ddata, pan fyddwch chi eisiau gweld graffiau neu rai adroddiadau ar ddigwyddiadau, mae yna wahanol caches. Ond yn yr adroddiad hwn ni fyddaf yn siarad amdanynt.
Ar gyfer MySQL mae Innodb_buffer_pool, a chriw o wahanol caches y gellir eu ffurfweddu hefyd.
Ond dyma'r prif rai:
- byfferau wedi'u rhannu;
- effeithiol_cache_size;
- rhannu_pwll.
Ar gyfer pob cronfa ddata, dywedais fod yna rai caches sy'n eich galluogi i storio yn RAM y data sydd ei angen yn aml ar gyfer ymholiadau. Mae ganddyn nhw eu technolegau eu hunain ar gyfer hyn.
Ynglŷn â Pherfformiad Cronfa Ddata
Yn unol â hynny, mae amgylchedd cystadleuol, hynny yw, mae gweinydd Zabbix yn casglu data ac yn ei gofnodi. Pan gaiff ei ailgychwyn, mae hefyd yn darllen o hanes i lenwi'r ValueCache ac yn y blaen. Yma gallwch gael sgriptiau ac adroddiadau sy'n defnyddio'r API Zabbix, sydd wedi'i adeiladu ar ryngwyneb gwe. Mae Zabbix API yn mynd i mewn i'r gronfa ddata ac yn derbyn y data angenrheidiol i gael graffiau, adroddiadau, neu ryw fath o restr o ddigwyddiadau, problemau diweddar.
Ateb delweddu poblogaidd iawn hefyd yw Grafana, y mae ein defnyddwyr yn ei ddefnyddio. Yn gallu mewngofnodi'n uniongyrchol trwy'r Zabbix API a thrwy'r gronfa ddata. Mae hefyd yn creu cystadleuaeth benodol ar gyfer cael data: mae angen tiwnio'r gronfa ddata yn fanylach ac yn well i gydymffurfio â chyflawni canlyniadau a phrofion yn gyflym.
Clirio hanes. Mae gan Zabbix Geidwad Tŷ
Y trydydd galwad a ddefnyddir yn Zabbix yw clirio hanes gan ddefnyddio Housekeeper. Mae ceidwad tŷ yn dilyn yr holl osodiadau, hynny yw, mae ein helfennau data yn nodi pa mor hir i storio (mewn dyddiau), pa mor hir i storio tueddiadau, a dynameg newidiadau.
Wnes i ddim siarad am TrendCache, rydyn ni'n ei gyfrifo ar y hedfan: mae data'n cyrraedd, rydyn ni'n ei agregu am awr (mae'r rhain yn bennaf yn niferoedd ar gyfer yr awr olaf), mae'r swm yn gyfartalog / lleiaf ac rydyn ni'n ei gofnodi unwaith yr awr yn y tabl o ddeinameg newidiadau (“Tueddiadau”) . Mae “Housekeeper” yn dechrau ac yn dileu data o'r gronfa ddata gan ddefnyddio detholiadau rheolaidd, nad yw bob amser yn effeithiol.
Sut i ddeall ei fod yn aneffeithiol? Gallwch weld y llun canlynol ar graffiau perfformiad prosesau mewnol:
Mae'ch syncer Hanes yn brysur drwy'r amser (graff coch). A'r graff “coch” sy'n mynd ar ei ben. Mae hwn yn “Gofalwr Tŷ” sy'n cychwyn ac yn aros i'r gronfa ddata ddileu'r holl resi y mae wedi'u nodi.
Gadewch i ni gymryd rhywfaint o ID Eitem: mae angen i chi ddileu'r 5 mil diwethaf; wrth gwrs, gan fynegeion. Ond fel arfer mae'r set ddata yn eithaf mawr - mae'r gronfa ddata yn dal i'w ddarllen o ddisg ac yn ei roi yn y storfa, ac mae hwn yn weithrediad drud iawn i'r gronfa ddata. Yn dibynnu ar ei faint, gall hyn arwain at rai problemau perfformiad.
Gallwch analluogi Cadw Tŷ mewn ffordd syml - mae gennym ryngwyneb gwe cyfarwydd. Gosodiadau mewn Gweinyddiaeth gyffredinol (gosodiadau ar gyfer “Housekeeper”) rydym yn analluogi cadw tŷ mewnol ar gyfer hanes mewnol a thueddiadau. Yn unol â hynny, nid yw'r Swyddog Cadw Tŷ yn rheoli hyn mwyach:
Beth allwch chi ei wneud nesaf? Rydych chi wedi'i ddiffodd, mae eich graffiau wedi lefelu... Pa broblemau pellach allai godi yn yr achos hwn? Beth all helpu?
Rhaniadu (rhanu)
Yn nodweddiadol mae hyn wedi'i ffurfweddu mewn ffordd wahanol ar bob cronfa ddata berthynol rydw i wedi'i rhestru. Mae gan MySQL ei dechnoleg ei hun. Ond ar y cyfan maent yn debyg iawn o ran PostgreSQL 10 a MySQL. Wrth gwrs, mae yna lawer o wahaniaethau mewnol o ran sut mae'r cyfan yn cael ei weithredu a sut mae'r cyfan yn effeithio ar berfformiad. Ond yn gyffredinol, mae creu rhaniad newydd yn aml hefyd yn arwain at rai problemau.
Yn dibynnu ar eich setup (faint o ddata rydych chi'n ei greu mewn un diwrnod), maen nhw fel arfer yn gosod yr isafswm - mae hyn yn 1 diwrnod / swp, ac ar gyfer “tueddiadau”, dynameg newidiadau - 1 mis / swp newydd. Gall hyn newid os oes gennych chi osodiad mawr iawn.
Gadewch i ni ddweud ar unwaith am faint y setup: hyd at 5 mil o werthoedd newydd yr eiliad (nvps fel y'i gelwir) - bydd hyn yn cael ei ystyried yn “setup” bach. Cyfartaledd - o 5 i 25 mil o werthoedd yr eiliad. Y cyfan sydd uchod yw gosodiadau mawr a mawr iawn sydd angen cyfluniad gofalus iawn o'r gronfa ddata.
Ar osodiadau mawr iawn, efallai na fydd 1 diwrnod yn optimaidd. Yn bersonol, rwyf wedi gweld rhaniadau ar MySQL o 40 gigabeit y dydd (ac efallai y bydd mwy). Mae hwn yn swm mawr iawn o ddata, a all arwain at rai problemau. Mae angen ei leihau.
Pam mae angen rhaniad arnoch chi?
Yr hyn y mae Partitioning yn ei ddarparu, rwy'n meddwl bod pawb yn ei wybod, yw rhaniad bwrdd. Yn aml mae'r rhain yn ffeiliau ar wahân ar ddisgiau a cheisiadau rhychwant. Mae'n dewis un rhaniad yn fwy optimaidd os yw'n rhan o raniad arferol.
Ar gyfer Zabbix, yn arbennig, fe'i defnyddir yn ôl amrediad, yn ôl amrediad, hynny yw, rydym yn defnyddio stamp amser (rhif rheolaidd, amser ers dechrau'r epoc). Rydych chi'n nodi dechrau'r diwrnod / diwedd y dydd, a dyma'r rhaniad. Yn unol â hynny, os ydych chi'n gofyn am ddata sy'n ddau ddiwrnod oed, mae popeth yn cael ei adfer o'r gronfa ddata yn gyflymach, oherwydd dim ond un ffeil sydd angen i chi ei lwytho i'r storfa a'i dychwelyd (yn hytrach na thabl mawr).
Mae llawer o gronfeydd data hefyd yn cyflymu mewnosod (gosod mewn un tabl plentyn). Rwy'n siarad yn haniaethol am y tro, ond mae hyn hefyd yn bosibl. Mae cymryd rhan yn aml yn helpu.
Elasticsearch ar gyfer NoSQL
Yn ddiweddar, yn 3.4, fe wnaethom weithredu datrysiad NoSQL. Ychwanegwyd y gallu i ysgrifennu yn Elasticsearch. Gallwch ysgrifennu rhai mathau: rydych chi'n dewis - naill ai ysgrifennu rhifau neu rai arwyddion; mae gennym destun llinynnol, gallwch ysgrifennu logiau i Elasticsearch... Yn unol â hynny, bydd y rhyngwyneb gwe hefyd yn cyrchu Elasticsearch. Mae hyn yn gweithio'n wych mewn rhai achosion, ond ar hyn o bryd gellir ei ddefnyddio.
AmserlenDB. Gorfyrddau
Ar gyfer 4.4.2 talwyd sylw i un peth fel TimescaleDB. Beth yw e? Mae hwn yn estyniad ar gyfer PostgreSQL, hynny yw, mae ganddo ryngwyneb PostgreSQL brodorol. Hefyd, mae'r estyniad hwn yn caniatáu ichi weithio'n llawer mwy effeithlon gyda data cyfres amser a chael rhaniad awtomatig. Sut mae'n edrych:
Mae hyn yn hypertable - mae cysyniad o'r fath yn yr Amserlen. Mae hwn yn hypertable rydych chi'n ei greu, ac mae'n cynnwys talpiau. Rhaniadau yw talpiau, byrddau plant yw'r rhain, os nad wyf yn camgymryd. Mae'n wirioneddol effeithiol.
AmserlenDB a PostgreSQL
Fel y mae gweithgynhyrchwyr TimescaleDB yn ei sicrhau, maent yn defnyddio algorithm mwy cywir ar gyfer prosesu ymholiadau, yn enwedig mewnosodiadau, sy'n caniatáu iddynt gael perfformiad eithaf cyson gyda maint cynyddol y mewnosodiad set ddata. Hynny yw, ar ôl 200 miliwn o resi o Postgres, mae'r un arferol yn dechrau sagio'n fawr iawn ac yn colli perfformiad yn llythrennol i sero, tra bod Amserlen yn caniatáu ichi fewnosod mewnosodiadau mor effeithlon â phosibl gydag unrhyw swm o ddata.
Sut i osod TimescaleDB? Mae'n syml!
Mae yn y ddogfennaeth, fe'i disgrifir - gallwch ei osod o becynnau ar gyfer unrhyw ... Mae'n dibynnu ar becynnau swyddogol Postgres. Gellir ei lunio â llaw. Digwyddodd felly bod yn rhaid i mi lunio ar gyfer y gronfa ddata.
Ar Zabbix rydym yn syml actifadu Estyniad. Rwy'n meddwl bod y rhai a ddefnyddiodd Estyniad yn Postgres... Yn syml, rydych chi'n actifadu Extention, yn ei greu ar gyfer y gronfa ddata Zabbix rydych chi'n ei defnyddio.
A'r cam olaf...
AmserlenDB. Mudo tablau hanes
Mae angen i chi greu hypertable. Mae swyddogaeth arbennig i hyn - Creu hypertable. Ynddo, y paramedr cyntaf yw'r tabl sydd ei angen yn y gronfa ddata hon (y mae angen i chi greu hypertable ar ei gyfer).
Y maes ar gyfer creu, a chunk_time_interval (dyma'r cyfwng talpiau (rhaniadau sydd angen eu defnyddio). 86 yw un diwrnod.
Paramedr Migrate_data: Os mewnosodwch i wir, yna bydd hyn yn mudo'r holl ddata cyfredol i dalpiau a grëwyd ymlaen llaw.
Rwyf wedi defnyddio migrate_data fy hun - mae'n cymryd cryn dipyn o amser, yn dibynnu ar ba mor fawr yw eich cronfa ddata. Cefais dros terabyte - cymerodd dros awr i greu. Mewn rhai achosion, yn ystod y profion, fe wnes i ddileu data hanesyddol ar gyfer testun (history_text) a llinyn (history_str) er mwyn peidio â'u trosglwyddo - nid oeddent yn ddiddorol iawn i mi.
Ac rydym yn gwneud y diweddariad diwethaf yn ein db_extention: rydym yn gosod timescaledb fel bod y gronfa ddata ac, yn benodol, ein Zabbix yn deall bod db_extention. Mae'n ei actifadu ac yn defnyddio'r gystrawen gywir ac ymholiadau i'r gronfa ddata, gan ddefnyddio'r “nodweddion” hynny sy'n angenrheidiol ar gyfer TimescaleDB.
Cyfluniad gweinydd
Defnyddiais ddau weinydd. Mae'r gweinydd cyntaf yn beiriant rhithwir eithaf bach, 20 prosesydd, 16 gigabeit o RAM. Fe wnes i ffurfweddu Postgres 10.8 arno:
Y system weithredu oedd Debian, y system ffeiliau oedd xfs. Gwneuthum y gosodiadau lleiaf posibl i ddefnyddio'r gronfa ddata benodol hon, namyn yr hyn y bydd Zabbix ei hun yn ei ddefnyddio. Ar yr un peiriant roedd gweinydd Zabbix, PostgreSQL ac asiantau llwyth.
Rwyf wedi defnyddio 50 o asiantau gweithredol sy'n defnyddio LoadableModule i gynhyrchu canlyniadau gwahanol yn gyflym. Nhw yw'r rhai a gynhyrchodd y llinynnau, y niferoedd, ac ati. Llenwais y gronfa ddata gyda llawer o ddata. I ddechrau, roedd y cyfluniad yn cynnwys 5 mil o elfennau data fesul gwesteiwr, ac roedd oddeutu pob elfen ddata yn cynnwys sbardun - er mwyn i hwn fod yn setup go iawn. Weithiau mae hyd yn oed angen mwy nag un sbardun i'w ddefnyddio.
Rheoleiddiais y cyfwng diweddaru a'r llwyth ei hun trwy nid yn unig ddefnyddio 50 o asiantau (ychwanegu mwy), ond hefyd gan ddefnyddio elfennau data deinamig a lleihau'r cyfwng diweddaru i 4 eiliad.
Prawf perfformiad. PostgreSQL: 36 mil NVPs
Y lansiad cyntaf, y setup cyntaf a gefais oedd ar PostreSQL 10 pur ar y caledwedd hwn (35 mil o werthoedd yr eiliad). Yn gyffredinol, fel y gwelwch ar y sgrin, mae mewnosod data yn cymryd ffracsiynau o eiliad - mae popeth yn dda ac yn gyflym, gyriannau SSD (200 gigabeit). Yr unig beth yw bod 20 GB yn llenwi'n eithaf cyflym.
Bydd cryn dipyn o graffiau o'r fath yn y dyfodol. Mae hwn yn ddangosfwrdd perfformiad gweinydd safonol Zabbix.
Y graff cyntaf yw nifer y gwerthoedd yr eiliad (glas, chwith uchaf), 35 mil o werthoedd yn yr achos hwn. Hwn (canol uchaf) yw llwytho prosesau adeiladu, a dyma (dde uchaf) yw llwytho prosesau mewnol: syncers hanes a chadw tŷ, sydd yma (canol gwaelod) wedi bod yn rhedeg ers cryn amser.
Mae'r graff hwn (canol gwaelod) yn dangos defnydd ValueCache - faint o drawiadau ValueCache ar gyfer sbardunau (sawl mil o werthoedd yr eiliad). Graff pwysig arall yw'r pedwerydd un (gwaelod chwith), sy'n dangos y defnydd o HistoryCache, y soniais amdano, sef byffer cyn ei fewnosod yn y gronfa ddata.
Prawf perfformiad. PostgreSQL: 50 mil NVPs
Nesaf, cynyddais y llwyth i 50 mil o werthoedd yr eiliad ar yr un caledwedd. Pan gafodd ei lwytho gan Housekeeper, cofnodwyd 10 mil o werthoedd mewn 2-3 eiliad gyda chyfrifiad. Beth, mewn gwirionedd, sy'n cael ei ddangos yn y sgrinlun canlynol:
Mae “Ceidwad tŷ” eisoes yn dechrau ymyrryd â gwaith, ond yn gyffredinol, mae'r llwyth ar draperwyr hanes-sinker yn dal i fod ar lefel 60% (trydydd graff, ar y dde uchaf). Mae HistoryCache eisoes yn dechrau llenwi'n weithredol tra bod Cadw Tŷ yn rhedeg (gwaelod chwith). Roedd tua hanner gigabeit, 20% yn llawn.
Prawf perfformiad. PostgreSQL: 80 mil NVPs
Yna cynyddais ef i 80 mil o werthoedd yr eiliad:
Roedd tua 400 mil o elfennau data, 280 mil o sbardunau. Roedd y mewnosodiad, fel y gwelwch, o ran y llwyth o sinkers hanes (roedd 30 ohonynt) eisoes yn eithaf uchel. Yna cynyddais baramedrau amrywiol: sinkers hanes, storfa ... Ar y caledwedd hwn, dechreuodd y llwyth ar sinwyr hanes gynyddu i'r eithaf, bron “ar y silff” - yn unol â hynny, aeth HistoryCache i mewn i lwyth uchel iawn:
Trwy'r amser hwn, fe wnes i fonitro holl baramedrau'r system (sut mae'r prosesydd yn cael ei ddefnyddio, RAM) a darganfod bod y defnydd o ddisg yn uchaf - cyflawnais gapasiti mwyaf y ddisg hon ar y caledwedd hwn, ar y peiriant rhithwir hwn. Dechreuodd "Postgres" ddympio data yn eithaf gweithredol ar ddwyster o'r fath, ac nid oedd gan y ddisg amser i ysgrifennu, darllen ...
Cymerais weinydd arall a oedd eisoes â 48 o broseswyr a 128 gigabeit o RAM:
Fe wnes i ei “diwnio” hefyd - gosod Syncer Hanes (60 darn) a chyflawni perfformiad derbyniol. Mewn gwirionedd, nid ydym “ar y silff,” ond mae'n debyg mai dyma derfyn cynhyrchiant, lle mae eisoes yn angenrheidiol gwneud rhywbeth yn ei gylch.
Prawf perfformiad. AmserlenDB: 80 mil NVPs
Fy mhrif dasg oedd defnyddio TimescaleDB. Mae pob graff yn dangos gostyngiad:
Mudo data yn union yw'r methiannau hyn. Ar ôl hynny, yn y gweinydd Zabbix, mae proffil llwytho sinkers hanes, fel y gwelwch, wedi newid llawer. Mae'n caniatáu ichi fewnosod data bron i 3 gwaith yn gyflymach a defnyddio llai o HistoryCache - yn unol â hynny, bydd gennych ddata wedi'i ddosbarthu mewn pryd. Unwaith eto, mae 80 mil o werthoedd yr eiliad yn gyfradd eithaf uchel (wrth gwrs, nid ar gyfer Yandex). Ar y cyfan mae hwn yn osodiad eithaf mawr, gydag un gweinydd.
Prawf perfformiad PostgreSQL: 120 mil o NVPs
Nesaf, cynyddais werth nifer yr elfennau data i hanner miliwn a derbyniais werth cyfrifedig o 125 mil yr eiliad:
A chefais y graffiau hyn:
Mewn egwyddor, mae hwn yn setup gweithio, gall weithio am amser eithaf hir. Ond gan mai dim ond disg 1,5 terabyte oedd gen i, fe wnes i ei ddefnyddio mewn cwpl o ddiwrnodau. Y peth pwysicaf yw bod rhaniadau newydd wedi'u creu ar yr un pryd ar TimescaleDB, ac roedd hyn yn gwbl ddisylw ar gyfer perfformiad, na ellir ei ddweud am MySQL.
Yn nodweddiadol, mae rhaniadau'n cael eu creu yn y nos, oherwydd mae hyn yn gyffredinol yn rhwystro gosod a gweithio gyda thablau a gall arwain at ddiraddio'r gwasanaeth. Yn yr achos hwn nid yw hyn yn wir! Y brif dasg oedd profi galluoedd TimescaleDB. Y canlyniad oedd y ffigur canlynol: 120 mil o werthoedd yr eiliad.
Mae yna hefyd enghreifftiau yn y gymuned:
Trodd y person hefyd TimescaleDB ymlaen a gostyngodd y llwyth ar ddefnyddio io.weight ar y prosesydd; ac mae'r defnydd o elfennau proses fewnol hefyd wedi lleihau oherwydd cynnwys AmserlenDB. Ar ben hynny, disgiau crempog cyffredin yw'r rhain, hynny yw, peiriant rhithwir cyffredin ar ddisgiau cyffredin (nid SSDs)!
Ar gyfer rhai gosodiadau bach sy'n gyfyngedig gan berfformiad disg, mae TimescaleDB, yn fy marn i, yn ateb da iawn. Bydd yn caniatáu ichi barhau i weithio cyn mudo i galedwedd cyflymach ar gyfer y gronfa ddata.
Rwy'n eich gwahodd i gyd i'n digwyddiadau: Cynhadledd ym Moscow, Uwchgynhadledd yn Riga. Defnyddiwch ein sianeli - Telegram, fforwm, IRC. Os oes gennych unrhyw gwestiynau, dewch at ein desg, gallwn siarad am bopeth.
Cwestiynau Cynulleidfa
Cwestiwn gan y gynulleidfa (o hyn ymlaen - A): - Os yw TimescaleDB mor hawdd i'w ffurfweddu, a'i fod yn rhoi hwb perfformiad o'r fath, yna efallai y dylid defnyddio hwn fel arfer gorau ar gyfer ffurfweddu Zabbix gyda Postgres? Ac a oes unrhyw beryglon ac anfanteision i'r ateb hwn, neu wedi'r cyfan, os penderfynais wneud Zabbix i mi fy hun, gallaf gymryd Postgres yn hawdd, gosod Amserlen yno ar unwaith, ei ddefnyddio a pheidio â meddwl am unrhyw broblemau?
AG: – Ydw, byddwn yn dweud bod hwn yn argymhelliad da: defnyddiwch Postgres ar unwaith gyda'r estyniad TimescaleDB. Fel y dywedais eisoes, mae llawer o adolygiadau da, er gwaethaf y ffaith bod y "nodwedd" hon yn arbrofol. Ond mewn gwirionedd mae profion yn dangos bod hwn yn ateb gwych (gydag TimescaleDB) a chredaf y bydd yn esblygu! Rydym yn monitro sut mae'r estyniad hwn yn datblygu a byddwn yn gwneud newidiadau yn ôl yr angen.
Hyd yn oed yn ystod datblygiad, roeddem yn dibynnu ar un o'u “nodweddion” adnabyddus: roedd yn bosibl gweithio gyda thapiau ychydig yn wahanol. Ond yna fe wnaethon nhw ei dorri allan yn y datganiad nesaf, a bu'n rhaid i ni roi'r gorau i ddibynnu ar y cod hwn. Byddwn yn argymell defnyddio'r datrysiad hwn ar lawer o setiau. Os ydych chi'n defnyddio MySQL... Ar gyfer gosodiadau arferol, mae unrhyw ddatrysiad yn gweithio'n dda.
A: - Ar y graffiau olaf o'r gymuned, roedd graff gyda “Housekeeper”:
Parhaodd i weithio. Beth mae Ceidwad Tŷ yn ei wneud ag AmserlenDB?
AG: - Nawr ni allaf ddweud yn sicr - edrychaf ar y cod a dweud wrthych yn fanylach. Mae'n defnyddio ymholiadau TimescaleDB i beidio â dileu talpiau, ond i'w hagregu rywsut. Nid wyf yn barod i ateb y cwestiwn technegol hwn eto. Cawn wybod mwy ar y stondin heddiw neu yfory.
A: – Mae gennyf gwestiwn tebyg – am berfformiad y gweithrediad dileu yn yr Amserlen.
A (ateb gan y gynulleidfa): - Pan fyddwch chi'n dileu data o dabl, os gwnewch hynny trwy ddileu, yna mae angen i chi fynd drwy'r tabl - dileu, glanhau, marcio popeth ar gyfer gwactod yn y dyfodol. Yn yr Amserlen, gan fod gennych chi dalpiau, gallwch chi ollwng. Yn fras, rydych chi'n dweud wrth y ffeil sydd mewn data mawr: "Dileu!"
Yn syml, mae'r amserlen yn deall nad yw talp o'r fath yn bodoli mwyach. A chan ei fod wedi'i integreiddio i'r cynlluniwr ymholiad, mae'n defnyddio bachau i ddal eich amodau mewn gweithrediadau dethol neu weithrediadau eraill ac mae'n deall ar unwaith nad yw'r darn hwn yn bodoli mwyach - "Ni fyddaf yn mynd yno mwyach!" (data ddim ar gael). Dyna i gyd! Hynny yw, mae sgan tabl yn cael ei ddisodli gan ddileu ffeil deuaidd, felly mae'n gyflym.
A: – Rydym eisoes wedi cyffwrdd â'r pwnc nad yw'n SQL. Cyn belled ag y deallaf, nid oes angen i Zabbix addasu'r data mewn gwirionedd, ac mae hyn i gyd yn rhywbeth fel log. A yw'n bosibl defnyddio cronfeydd data arbenigol na allant newid eu data, ond ar yr un pryd arbed, cronni, a dosbarthu'n llawer cyflymach - Clickhouse, er enghraifft, rhywbeth tebyg i Kafka?... Mae Kafka hefyd yn log! A yw'n bosibl eu hintegreiddio rywsut?
AG: - Gellir dadlwytho. Mae gennym “nodwedd” benodol ers fersiwn 3.4: gallwch chi ysgrifennu pob ffeil hanesyddol, digwyddiad, popeth arall i ffeiliau; ac yna ei anfon i unrhyw gronfa ddata arall gan ddefnyddio rhyw driniwr. Mewn gwirionedd, mae llawer o bobl yn ail-weithio ac yn ysgrifennu'n uniongyrchol i'r gronfa ddata. Ar y hedfan, mae sinwyr hanes yn ysgrifennu hyn i gyd i mewn i ffeiliau, yn cylchdroi'r ffeiliau hyn, ac yn y blaen, a gallwch chi drosglwyddo hyn i Clickhouse. Ni allaf ddweud am gynlluniau, ond efallai y bydd cefnogaeth bellach i atebion NoSQL (fel Clickhouse) yn parhau.
A: - Yn gyffredinol, mae'n ymddangos y gallwch chi gael gwared ar y postgres yn llwyr?
AG: - Wrth gwrs, y rhan anoddaf yn Zabbix yw'r tablau hanesyddol, sy'n creu'r problemau a'r digwyddiadau mwyaf. Yn yr achos hwn, os na fyddwch chi'n storio digwyddiadau am amser hir ac yn storio'r hanes gyda thueddiadau mewn rhai storio cyflym eraill, yna yn gyffredinol, rwy'n meddwl, ni fydd unrhyw broblemau.
A: - A allwch chi amcangyfrif faint yn gyflymach y bydd popeth yn gweithio os byddwch chi'n newid i Clickhouse, er enghraifft?
AG: - Nid wyf wedi ei brofi. Credaf y gellir cyflawni o leiaf yr un niferoedd yn eithaf syml, o ystyried bod gan Clickhouse ei ryngwyneb ei hun, ond ni allaf ddweud yn sicr. Mae'n well profi. Mae'r cyfan yn dibynnu ar y ffurfweddiad: faint o westeion sydd gennych, ac ati. Mae mewnosod yn un peth, ond mae angen i chi hefyd adfer y data hwn - Grafana neu rywbeth arall.
A: - Felly rydym yn sôn am frwydr gyfartal, ac nid am fantais fawr y cronfeydd data cyflym hyn?
AG: - Rwy'n meddwl pan fyddwn yn integreiddio, bydd profion mwy cywir.
A: – Ble aeth hen RRD da? Beth wnaeth i chi newid i gronfeydd data SQL? I ddechrau, casglwyd yr holl fetrigau ar RRD.
AG: - Roedd gan Zabbix RRD, efallai mewn fersiwn hynafol iawn. Bu cronfeydd data SQL erioed - dull clasurol. Y dull clasurol yw MySQL, PostgreSQL (maen nhw wedi bodoli ers amser maith). Ni wnaethom bron erioed ddefnyddio rhyngwyneb cyffredin ar gyfer cronfeydd data SQL a RRD.
Rhai hysbysebion 🙂
Diolch am aros gyda ni. Ydych chi'n hoffi ein herthyglau? Eisiau gweld cynnwys mwy diddorol? Cefnogwch ni trwy osod archeb neu argymell i ffrindiau, , analog unigryw o weinyddion lefel mynediad, a ddyfeisiwyd gennym ni ar eich cyfer chi: (ar gael gyda RAID1 a RAID10, hyd at 24 craidd a hyd at 40GB DDR4).
Dell R730xd 2 gwaith yn rhatach yng nghanolfan ddata Equinix Haen IV yn Amsterdam? Dim ond yma yn yr Iseldiroedd! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - o $99! Darllenwch am
Ffynhonnell: hab.com