Mae Zabbix yn system fonitro. Fel unrhyw system arall, mae'n wynebu tair prif broblem o'r holl systemau monitro: casglu a phrosesu data, storio hanes, a'i lanhau.
Mae'r camau o dderbyn, prosesu a chofnodi data yn cymryd amser. Dim llawer, ond ar gyfer system fawr gall hyn arwain at oedi mawr. Mae'r broblem storio yn fater mynediad data. Fe'u defnyddir ar gyfer adroddiadau, gwiriadau a sbardunau. Mae cuddni mewn mynediad at ddata hefyd yn effeithio ar berfformiad. Pan fydd cronfeydd data yn tyfu, mae'n rhaid dileu data amherthnasol. Mae cael gwared yn weithrediad anodd sydd hefyd yn bwyta rhai adnoddau.
Mae problemau oedi wrth gasglu a storio yn Zabbix yn cael eu datrys trwy caching: sawl math o caches, caching yn y gronfa ddata. I ddatrys y drydedd broblem, nid yw caching yn addas, felly defnyddiodd Zabbix TimescaleDB. Bydd yn dweud wrthych amdano Andrey Gushchin - peiriannydd cymorth technegol . Mae Andrey wedi bod yn cefnogi Zabbix am fwy na 6 mlynedd ac mae ganddo brofiad uniongyrchol gyda pherfformiad.
Sut mae TimescaleDB yn gweithio, pa berfformiad y gall ei roi o'i gymharu â PostgreSQL rheolaidd? Pa rôl mae Zabbix yn ei chwarae ar gyfer cronfa ddata TimescaleDB? Sut i ddechrau o'r dechrau a sut i fudo o PostgreSQL a pha gyfluniad sydd â pherfformiad gwell? Ynglŷn â hyn i gyd o dan y toriad.
Heriau Cynhyrchiant
Mae pob system fonitro yn wynebu heriau perfformiad penodol. Soniaf am dri ohonynt: casglu a phrosesu data, storio, a chlirio hanes.
Casglu a phrosesu data yn gyflym. Dylai system fonitro dda dderbyn yr holl ddata yn gyflym a'i brosesu yn unol â mynegiadau sbardun - yn ôl ei feini prawf. Ar ôl prosesu, rhaid i'r system hefyd arbed y data hwn yn gyflym yn y gronfa ddata i'w ddefnyddio'n ddiweddarach.
Storio hanes. Dylai system fonitro dda storio hanes mewn cronfa ddata a darparu mynediad hawdd i fetrigau. Mae angen defnyddio hanes mewn adroddiadau, graffiau, sbardunau, trothwyon, ac eitemau data rhybuddio wedi'u cyfrifo.
Clirio hanes. Weithiau daw diwrnod pan nad oes angen i chi storio metrigau. Pam mae angen data a gasglwyd 5 mlynedd yn ôl, mis neu ddau: mae rhai nodau wedi'u dileu, nid oes angen rhai gwesteiwyr neu fetrigau mwyach oherwydd eu bod yn hen ffasiwn ac nad ydynt bellach yn cael eu casglu. Dylai system fonitro dda storio data hanesyddol a'i ddileu o bryd i'w gilydd fel nad yw'r gronfa ddata yn tyfu.
Mae glanhau hen ddata yn fater hollbwysig sy'n effeithio'n fawr ar berfformiad cronfa ddata.
Caching yn Zabbix
Yn Zabbix, mae'r alwad gyntaf a'r ail alwad yn cael eu datrys gan ddefnyddio caching. Defnyddir RAM i gasglu a phrosesu data. Ar gyfer storio - hanes mewn sbardunau, graffiau ac elfennau data wedi'u cyfrifo. Ar ochr y gronfa ddata mae rhywfaint o caching ar gyfer dewisiadau sylfaenol, er enghraifft, graffiau.
Yn cadw ar ochr y gweinydd Zabbix ei hun mae:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Gadewch i ni eu hystyried yn fwy manwl.
ConfigurationCache
Dyma'r brif storfa lle rydym yn storio metrigau, gwesteiwyr, eitemau data, sbardunau - popeth sydd ei angen arnom ar gyfer PreProcessing ac ar gyfer casglu data.
Mae hyn i gyd yn cael ei storio yn ConfigurationCache er mwyn peidio â chreu ymholiadau diangen yn y gronfa ddata. Ar ôl i'r gweinydd ddechrau, rydym yn diweddaru'r storfa hon, yn creu ac yn diweddaru ffurfweddiadau o bryd i'w gilydd.
Casglu data
Mae'r diagram yn eithaf mawr, ond y prif beth ynddo yw casglwyr. Mae'r rhain yn “bolwyr” amrywiol - prosesau cydosod. Maent yn gyfrifol am wahanol fathau o gynulliadau: maent yn casglu data trwy SNMP, IPMI, ac yn trosglwyddo'r cyfan i PreProcessing.
Amlinellir y casglwyr mewn oren.
Mae Zabbix wedi cyfrifo eitemau agregu sydd eu hangen i agregu gwiriadau. Os oes gennym ni nhw, rydyn ni'n nôl y data ar eu cyfer yn uniongyrchol o'r ValueCache.
PreProcessing HistoryCache
Mae pob casglwr yn defnyddio ConfigurationCache i dderbyn swyddi. Yna maent yn eu trosglwyddo i PreProcessing.
Mae PreProcessing yn defnyddio ConfigurationCache i dderbyn camau PreProcessing. Mae'n prosesu'r data hwn mewn gwahanol ffyrdd.
Ar ôl prosesu'r data gan ddefnyddio PreProcessing, rydym yn ei gadw yn HistoryCache i'w brosesu. Mae hyn yn dod â'r casgliad data i ben ac rydym yn symud ymlaen i'r brif broses yn Zabbix - syncer hanes, gan ei fod yn bensaernïaeth monolithig.
Nodyn: Mae PreProcessing yn weithrediad eithaf anodd. Gyda v 4.2 mae wedi'i symud i ddirprwy. Os oes gennych chi Zabbix mawr iawn gyda nifer fawr o elfennau data ac amlder casglu, yna mae hyn yn gwneud y gwaith yn llawer haws.
ValueCache, storfa hanes a thueddiadau
Syncer hanes yw'r brif broses sy'n prosesu pob elfen ddata yn atomig, hynny yw, pob gwerth.
Mae syncer hanes yn cymryd gwerthoedd o HistoryCache ac yn gwirio Ffurfweddiad ar gyfer presenoldeb sbardunau ar gyfer cyfrifiadau. Os ydynt yn bodoli, mae'n cyfrifo.
Mae cysonwr hanes yn creu digwyddiad, uwchgyfeirio i greu rhybuddion os oes angen trwy ffurfweddiad, a chofnodion. Os oes sbardunau ar gyfer prosesu dilynol, yna mae'n storio'r gwerth hwn yn ValueCache er mwyn peidio â chael mynediad i'r tabl hanes. Dyma sut mae ValueCache yn cael ei lenwi â data sy'n angenrheidiol i gyfrifo sbardunau ac elfennau wedi'u cyfrifo.
Mae syncer hanes yn ysgrifennu'r holl ddata i'r gronfa ddata, ac mae'n ysgrifennu i ddisg. Daw'r broses brosesu i ben yma.
Cadw yn y gronfa ddata
Ar ochr y gronfa ddata mae yna wahanol caches pan fyddwch chi eisiau gweld graffiau neu adroddiadau ar ddigwyddiadau:
Innodb_buffer_poolar yr ochr MySQL;shared_buffersar ochr PostgreSQL;effective_cache_sizear ochr Oracle;shared_poolar yr ochr DB2.
Mae yna lawer o caches eraill, ond dyma'r prif rai ar gyfer pob cronfa ddata. Maent yn caniatáu ichi storio data mewn RAM sydd ei angen yn aml ar gyfer ymholiadau. Mae ganddyn nhw eu technolegau eu hunain ar gyfer hyn.
Mae perfformiad cronfa ddata yn hollbwysig
Mae gweinydd Zabbix yn casglu data yn gyson ac yn ei ysgrifennu. Pan gaiff ei ailgychwyn, mae hefyd yn darllen o hanes i lenwi'r ValueCache. Yn defnyddio sgriptiau ac adroddiadau Zabbix API, sydd wedi'i adeiladu ar ryngwyneb Gwe. Mae Zabbix API yn cyrchu'r gronfa ddata ac yn adfer y data angenrheidiol ar gyfer graffiau, adroddiadau, rhestrau digwyddiadau a materion diweddaraf.
Ar gyfer delweddu - Grafana. Mae hwn yn ateb poblogaidd ymhlith ein defnyddwyr. Gall anfon ceisiadau yn uniongyrchol trwy'r Zabbix API ac i'r gronfa ddata, ac mae'n creu cystadleuaeth benodol ar gyfer derbyn data. Felly, mae angen tiwnio'r gronfa ddata yn fanylach ac yn well i gyd-fynd â chyflawni canlyniadau a phrofion yn gyflym.
cadw tŷ
Y drydedd her perfformiad yn Zabbix yw clirio hanes gan ddefnyddio Housekeeper. Mae'n dilyn yr holl osodiadau - mae'r elfennau data yn nodi pa mor hir i storio dynameg newidiadau (tueddiadau) mewn dyddiau.
Rydym yn cyfrifo TrendsCache ar y hedfan. Pan fydd y data'n cyrraedd, rydym yn ei agregu am awr ac yn ei gofnodi mewn tablau ar gyfer dynameg newidiadau tueddiadau.
Mae swyddog cadw tŷ yn dechrau ac yn dileu gwybodaeth o'r gronfa ddata gan ddefnyddio'r “dewisiadau” arferol. Nid yw hyn bob amser yn effeithiol, fel y gwelir o graffiau perfformiad prosesau mewnol.
Mae'r graff coch yn dangos bod y syncer History yn brysur yn gyson. Y graff oren ar y brig yw Housekeeper, sy'n rhedeg yn gyson. Mae'n aros i'r gronfa ddata ddileu'r holl resi a nododd.
Pryd ddylech chi analluogi Cadw Tŷ? Er enghraifft, mae "ID Eitem" ac mae angen i chi ddileu'r 5 mil o resi olaf o fewn amser penodol. Wrth gwrs, mae hyn yn digwydd yn ôl mynegai. Ond fel arfer mae'r set ddata yn fawr iawn, ac mae'r gronfa ddata yn dal i ddarllen o ddisg a'i roi yn y storfa. Mae hwn bob amser yn weithrediad drud iawn i'r gronfa ddata ac, yn dibynnu ar faint y gronfa ddata, gall arwain at broblemau perfformiad.
Mae'n hawdd analluogi cadw tŷ. Yn y rhyngwyneb Gwe mae gosodiad yn “Administration general” ar gyfer Cadw Tŷ. Rydym yn analluogi Cadw Tŷ mewnol ar gyfer hanes tueddiadau mewnol ac nid yw bellach yn ei reoli.
Cafodd swyddog cadw tŷ ei ddiffodd, lefelwyd y graffiau - pa broblemau allai fod yn yr achos hwn a beth allai helpu i ddatrys y trydydd her perfformiad?
Rhaniadu - rhaniad neu raniad
Yn nodweddiadol, mae rhaniad wedi'i ffurfweddu mewn ffordd wahanol ar bob cronfa ddata berthynol yr wyf wedi'i rhestru. Mae gan bob un ei dechnoleg ei hun, ond maent yn debyg yn gyffredinol. Mae creu rhaniad newydd yn aml yn arwain at rai problemau.
Yn nodweddiadol, mae rhaniadau'n cael eu ffurfweddu yn dibynnu ar y "setup" - faint o ddata sy'n cael ei greu mewn un diwrnod. Fel rheol, mae Rhaniad yn cael ei gyhoeddi mewn un diwrnod, dyma'r lleiafswm. Ar gyfer tueddiadau o swp newydd - 1 mis.
Gall y gwerthoedd newid os yw'r “setup” yn fawr iawn. Os yw “setup” bach hyd at 5 nvps (gwerthoedd newydd yr eiliad), mae un canolig rhwng 000 a 5, yna mae un mawr yn uwch na 000 nvps. Mae'r rhain yn osodiadau mawr a mawr iawn sydd angen cyfluniad gofalus o'r gronfa ddata.
Ar osodiadau mawr iawn, efallai na fydd cyfnod o un diwrnod yn optimaidd. Rwyf wedi gweld rhaniadau MySQL o 40 GB neu fwy y dydd. Mae hwn yn swm mawr iawn o ddata a all achosi problemau ac mae angen ei leihau.
Beth mae Partitioning yn ei roi?
Tablau rhaniad. Yn aml mae'r rhain yn ffeiliau ar wahân ar ddisg. Mae'r cynllun ymholiad yn dewis un rhaniad yn fwy optimaidd. Fel arfer defnyddir rhaniad yn ôl amrediad - mae hyn hefyd yn wir am Zabbix. Rydyn ni’n defnyddio “timestamp” yno – amser ers dechrau’r cyfnod. Mae'r rhain yn niferoedd cyffredin i ni. Rydych chi'n gosod dechrau a diwedd y dydd - dyma raniad.
Tynnu cyflym - DELETE. Dewisir un ffeil/is-tabl, yn hytrach na detholiad o resi i'w dileu.
Cyflymu'r broses o adalw data yn sylweddol SELECT - yn defnyddio un rhaniad neu fwy, yn hytrach na'r tabl cyfan. Os ydych chi'n cyrchu data sy'n ddeuddydd oed, mae'n cael ei adfer o'r gronfa ddata yn gyflymach oherwydd dim ond un ffeil sydd angen i chi ei lwytho i mewn i'r storfa a'i dychwelyd, nid bwrdd mawr.
Yn aml mae llawer o gronfeydd data yn cael eu cyflymu hefyd INSERT — mewnosodiadau yn y bwrdd plentyn.
AmserlenDB
Ar gyfer v 4.2, troesom ein sylw at AmserlenDB. Mae hwn yn estyniad ar gyfer PostgreSQL gyda rhyngwyneb brodorol. Mae'r estyniad yn gweithio'n effeithiol gyda data cyfres amser, heb golli buddion cronfeydd data perthynol. Mae TimescaleDB hefyd yn rhannu'n awtomatig.
Mae gan AmserlenDB gysyniad gorfeddwl (hypertable) rydych chi'n ei greu. Mae'n cynnwys talpiau - rhaniadau. Mae talpiau yn ddarnau hypertable a reolir yn awtomatig nad ydynt yn effeithio ar ddarnau eraill. Mae gan bob talp ei ystod amser ei hun.
AmserlenDB yn erbyn PostgreSQL
Mae TimescaleDB yn gweithio'n effeithlon iawn. Mae gweithgynhyrchwyr yr estyniad yn honni eu bod yn defnyddio algorithm prosesu ymholiad mwy cywir, yn enwedig inserts . Wrth i faint mewnosod y set ddata dyfu, mae'r algorithm yn cynnal perfformiad cyson.
Ar ôl 200 miliwn o resi, mae PostgreSQL fel arfer yn dechrau sagio'n sylweddol ac yn colli perfformiad i 0. Mae TimescaleDB yn caniatáu ichi fewnosod “mewnosod” yn effeithlon ar gyfer unrhyw swm o ddata.
Gosod
Mae gosod TimescaleDB yn weddol hawdd ar gyfer unrhyw becyn. YN disgrifir popeth yn fanwl - mae'n dibynnu ar becynnau swyddogol PostgreSQL. Gall TimescaleDB hefyd gael ei adeiladu a'i lunio â llaw.
Ar gyfer cronfa ddata Zabbix yn syml, rydym yn actifadu'r estyniad:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Rydych chi'n actifadu extension a'i greu ar gyfer cronfa ddata Zabbix. Y cam olaf yw creu hypertable.
Mudo tablau hanes i TimescaleDB
Mae swyddogaeth arbennig i hyn 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
Mae gan y swyddogaeth dri pharamedr. Yn gyntaf - tabl yn y gronfa ddata, y mae angen i chi greu hypertable ar ei gyfer. Ail - maes, yn ôl y mae angen i chi greu chunk_time_interval — cyfwng talpiau pared i'w defnyddio. Yn fy achos i, yr egwyl yw un diwrnod - 86.
Trydydd paramedr - migrate_data. Os ydych chi'n gosod true, yna trosglwyddir yr holl ddata cyfredol i dalpiau a grëwyd ymlaen llaw. Fe wnes i ei ddefnyddio fy hun migrate_data. Cefais tua 1 TB, a gymerodd dros awr. Hyd yn oed mewn rhai achosion, yn ystod y profion, fe wnes i ddileu data hanesyddol o fathau o gymeriadau nad oedd eu hangen ar gyfer storio, er mwyn peidio â'u trosglwyddo.
Cam olaf - UPDATE: yn db_extension rhoi timescaledbfel bod y gronfa ddata yn deall bod yr estyniad hwn yn bodoli. Mae Zabbix yn ei actifadu ac yn defnyddio'r gystrawen ac ymholiadau i'r gronfa ddata yn gywir - y nodweddion hynny sy'n angenrheidiol ar gyfer TimescaleDB.
Cyfluniad caledwedd
Defnyddiais ddau weinydd. Yn gyntaf - peiriant VMware. Mae'n eithaf bach: 20 proseswyr Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, 16 GB o RAM a SSD 200 GB.
Gosodais PostgreSQL 10.8 arno gyda system ffeiliau Debian 10.8-1.pgdg90+1 OS a xfs. Fe wnes i ffurfweddu popeth cyn lleied â phosibl i ddefnyddio'r gronfa ddata benodol hon, heb yr hyn y bydd Zabbix ei hun yn ei ddefnyddio.
Ar yr un peiriant roedd gweinydd Zabbix, PostgreSQL a asiantau llwyth. Roedd gen i 50 o asiantau gweithredol a oedd yn defnyddio LoadableModulei gynhyrchu canlyniadau gwahanol yn gyflym iawn: rhifau, tannau. Llenwais y gronfa ddata gyda llawer o ddata.
I ddechrau y cyfluniad a gynhwysir 5 o eitemau data fesul gwesteiwr. Roedd bron pob elfen yn cynnwys sbardun i'w wneud yn debyg i osodiadau go iawn. Mewn rhai achosion roedd mwy nag un sbardun. Ar gyfer un nod rhwydwaith roedd 3-000 o sbardunau.
Cyfwng Diweddaru Eitem Data − 4-7 eiliad. Rheoleiddiais y llwyth ei hun trwy ddefnyddio nid yn unig 50 o asiantau, ond ychwanegu mwy. Hefyd, gan ddefnyddio elfennau data, addasais y llwyth yn ddeinamig a lleihau'r cyfwng diweddaru i 4 s.
PostgreSQL. 35 nvps
Roedd fy rhediad cyntaf ar y caledwedd hwn ar PostgreSQL pur - 35 mil o werthoedd yr eiliad. Fel y gwelwch, mae mewnosod data yn cymryd ffracsiynau o eiliad - mae popeth yn dda ac yn gyflym. Yr unig beth yw bod disg SSD 200 GB yn llenwi'n gyflym.
Mae hwn yn ddangosfwrdd perfformiad gweinydd safonol Zabbix.
Y graff glas cyntaf yw nifer y gwerthoedd yr eiliad. Yr ail graff ar y dde yw llwytho prosesau adeiladu. Y trydydd yw llwytho prosesau adeiladu mewnol: syncers hanes a Housekeeper, sydd wedi bod yn rhedeg yma ers cryn amser.
Mae'r pedwerydd graff yn dangos defnydd HistoryCache. Mae hwn yn fath o glustog cyn ei fewnosod yn y gronfa ddata. Mae'r pumed graff gwyrdd yn dangos defnydd ValueCache, hynny yw, faint o drawiadau ValueCache ar gyfer sbardunau - dyma sawl mil o werthoedd yr eiliad.
PostgreSQL. 50 nvps
Yna cynyddais y llwyth i 50 mil o werthoedd yr eiliad ar yr un caledwedd.
Wrth lwytho o Housekeeper, cymerodd mewnosod 10 mil o werthoedd 2-3 eiliad.
Mae'r swyddog cadw tŷ eisoes yn dechrau ymyrryd â'r gwaith.
Mae'r trydydd graff yn dangos, yn gyffredinol, bod y llwyth ar drapers a synchers hanes yn dal i fod yn 60%. Yn y pedwerydd graff, mae HistoryCache eisoes yn dechrau llenwi'n eithaf gweithredol yn ystod gweithrediad Cadw Tŷ. Mae'n 20% llawn, sef tua 0,5 GB.
PostgreSQL. 80 nvps
Yna cynyddais y llwyth i 80 mil o werthoedd yr eiliad. Mae hyn tua 400 mil o elfennau data a 280 mil o sbardunau.
Mae cost llwytho tri deg o synchers hanes eisoes yn eithaf uchel.
Rwyf hefyd yn cynyddu paramedrau amrywiol: syncers hanes, caches.
Ar fy nghaledwedd, cynyddodd llwytho syncers hanes i'r eithaf. Roedd HistoryCache yn llenwi'n gyflym â data - roedd data ar gyfer prosesu wedi cronni yn y byffer.
Yr holl amser hwn sylwais sut y defnyddiwyd y prosesydd, RAM a pharamedrau system eraill, a darganfyddais fod y defnydd o ddisg ar ei uchaf.
Rwyf wedi cyflawni'r defnydd galluoedd disg uchaf ar y caledwedd hwn ac ar y peiriant rhithwir hwn. Gyda dwyster o'r fath, dechreuodd PostgreSQL fflysio data yn eithaf gweithredol, ac nid oedd gan y ddisg amser i ysgrifennu a darllen mwyach.
Ail weinydd
Cymerais weinydd arall, a oedd eisoes â phroseswyr 48 a 128 GB o RAM. Fe wnes i ei diwnio - ei osod i 60 syncer hanes, a chyflawni perfformiad derbyniol.
Mewn gwirionedd, dyma derfyn cynhyrchiant eisoes lle mae angen gwneud rhywbeth.
AmserlenDB. 80 nvps
Fy mhrif dasg yw profi galluoedd TimescaleDB yn erbyn llwyth Zabbix. Mae 80 mil o werthoedd yr eiliad yn llawer, amlder casglu metrigau (ac eithrio Yandex, wrth gwrs) a “gosodiad” eithaf mawr.
Mae yna ostyngiad ym mhob graff - dyma'n union y mudo data. Ar ôl methiannau yn y gweinydd Zabbix, newidiodd proffil llwytho'r syncer hanes yn fawr - fe ddisgynnodd dair gwaith.
Mae TimescaleDB yn caniatáu ichi fewnosod data bron i 3 gwaith yn gyflymach a defnyddio llai o HistoryCache.
Yn unol â hynny, byddwch yn derbyn data mewn modd amserol.
AmserlenDB. 120 nvps
Yna cynyddais nifer yr elfennau data i 500 mil. Y prif dasg oedd profi galluoedd TimescaleDB - cefais werth cyfrifedig o 125 mil o werthoedd yr eiliad.
Mae hwn yn “setup” gweithredol a all weithio am amser hir. Ond gan mai dim ond 1,5 TB oedd fy disg, fe wnes i ei lenwi mewn ychydig ddyddiau.
Y peth pwysicaf yw bod rhaniadau TimescaleDB newydd wedi'u creu ar yr un pryd.
Mae hyn yn gwbl ansylw ar gyfer perfformiad. Pan grëir rhaniadau yn MySQL, er enghraifft, mae popeth yn wahanol. Mae hyn fel arfer yn digwydd gyda'r nos oherwydd ei fod yn blocio mewnosodiad cyffredinol, yn gweithio gyda thablau ac yn gallu creu diraddio gwasanaeth. Nid yw hyn yn wir gydag AmserlenDB.
Fel enghraifft, byddaf yn dangos un graff o lawer yn y gymuned. Yn y llun, mae TimescaleDB wedi'i alluogi, diolch y mae'r llwyth ar ddefnyddio io.weight ar y prosesydd wedi gostwng. Gostyngodd y defnydd o elfennau proses fewnol hefyd. Ar ben hynny, mae hwn yn beiriant rhithwir cyffredin ar ddisgiau crempog cyffredin, nid SSD.
Canfyddiadau
Mae TimescaleDB yn ateb da ar gyfer "gosod" bach, sy'n effeithio ar berfformiad disg. Bydd yn caniatáu ichi barhau i weithio'n dda nes bod y gronfa ddata yn cael ei symud i galedwedd cyn gynted â phosibl.
Mae TimescaleDB yn hawdd i'w ffurfweddu, yn rhoi enillion perfformiad, yn gweithio'n dda gyda Zabbix a mae ganddo fanteision dros PostgreSQL.
Os ydych chi'n defnyddio PostgreSQL ac nad ydych chi'n bwriadu ei newid, rwy'n argymell defnyddio PostgreSQL gyda'r estyniad TimescaleDB ar y cyd â Zabbix. Mae'r ateb hwn yn gweithio'n effeithiol hyd at "setup" canolig.
Pan rydyn ni'n dweud “perfformiad uchel” rydyn ni'n ei olygu . Ni fydd yn rhaid i chi aros yn hir i ddysgu am y technolegau a'r arferion sy'n galluogi gwasanaethau i wasanaethu miliynau o ddefnyddwyr. Rhestr ar gyfer Tachwedd 7 ac 8 rydym eisoes wedi llunio, ond yma gellir awgrymu mwy.
Tanysgrifiwch i'n и , lle rydym yn datgelu nodweddion y gynhadledd sydd i ddod, ac yn darganfod sut i gael y gorau ohoni.
Ffynhonnell: hab.com