Zabbix â Ă«shtĂ« njĂ« sistem monitorimi. Ashtu si çdo sistem tjetĂ«r, ajo pĂ«rballen me tre problemet kryesore qĂ« kanĂ« tĂ« gjitha sistemet e monitorimit: mbledhja dhe pĂ«rpunimi i tĂ« dhĂ«nave, ruajtja e historisĂ« dhe pastrimi i saj.
Hapat e marrjes, përpunimit dhe shkrimit të të dhënave marrin kohë. Pak, por për një sistem të madh, kjo mund të krijojë vonesa të mëdha. Problemi i ruajtjes është çështje e qasjes në të dhëna. Ato përdoren për raporte, kontrolle dhe trigger. Vonesat në qasjen në të dhëna gjithashtu ndikojnë në performancën. Kur DB-të rriten, të dhënat e paarsyeshme duhet të fshihen. Fshirja është një operacion i rëndë, i cili gjithashtu merr disa nga burimet.
Problemet e vonesave nĂ« mbledhjen dhe ruajtjen nĂ« Zabbix zgjidhen pĂ«rmes caching: disa lloje caches, caching nĂ« DB. PĂ«r tĂ« zgjidhur problemin e tretĂ«, caching nuk Ă«shtĂ« i pĂ«rshtatshĂ«m, ndaj Zabbix pĂ«rdori TimescaleDB. KĂ«saj do t'i flasĂ« Andrej Gushin â inxhinier i mbĂ«shtetjes teknike . NĂ« mbĂ«shtetje tĂ« Zabbix, Andrej ka mĂ« shumĂ« se 6 vjet dhe pĂ«rballet drejtpĂ«rdrejt me performancĂ«n.
Si si punon TimescaleDB, cila është performanca që mund të ofrojë krahasuar me PostgreSQL të zakonshëm? Cila është roli i Zabbix për bazën e të dhënave TimescaleDB? Si mund të filloni nga fillimi dhe si të emigroni nga PostgreSQL dhe cila konfigurim ofron performancën më të mirë? Për të gjitha këto, ndiqni më poshtë.
Sfidat e performancës
Ădo sistem monitorimi pĂ«rballet me sfida tĂ« caktuara performancĂ«s. UnĂ« do tĂ« flas pĂ«r tre nga ato: mbledhja dhe pĂ«rpunimi i tĂ« dhĂ«nave, ruajtja, pastrimi i historikut.
Mbledhja dhe përpunimi i shpejtë i të dhënave. Një sistem monitorimi i mirë duhet të marrë dhe të përpunojë të dhënat në mënyrë operative sipas shprehjeve të triggerit - sipas kritereve të tij. Pas përpunimit, sistemi gjithashtu duhet të ruajë shpejt këto të dhëna në bazën e të dhënave për t'i përdorur më vonë.
Ruajtja e historisë. Një sistem monitorimi i mirë duhet të ruajë historinë në bazën e të dhënave dhe të ofrojë akses të lehtë në metrikat. Historia është e nevojshme për t'u përdorur në raporte, grafika, triggers, vlerat prag dhe elementët e dhënash të llogaritur për alarmim.
Pastrimi i historisë. Ndonjëherë vjen dita kur nuk keni nevojë të ruani metrikat. Pse do t'ju duhen të dhënat që u mblodhën 5 vjet më parë, një muaj ose dy: disa njësitë janë fshirë, disa hoste ose metrika nuk janë më të nevojshme sepse janë bërë të vjetra dhe nuk mblidhen më. Një sistem i mirë monitorimi duhet të ruajë të dhëna historike dhe herë pas here t'i fshijë ato, në mënyrë që databaza të mos rritet tepër.
Pastrimi i të dhënave të vjetra është një çështje kritike që ka një ndikim të madh në performancën e bazës së të dhënave.
Kashimi në Zabbix
NĂ« Zabbix, thirrjet e para dhe tĂ« dyta zgjidhen pĂ«rmes kashimit. PĂ«rdoret memorje e pĂ«rkohshme pĂ«r mbledhjen dhe pĂ«rpunimin e tĂ« dhĂ«nave. PĂ«r ruajtjen â historiku nĂ« triggera, grafika dhe elementĂ« tĂ« dhĂ«nash tĂ« llogaritur. NĂ« anĂ«n e databazĂ«s ka njĂ« kashim tĂ« caktuar pĂ«r zgjedhjet kryesore, siç janĂ« grafikat.
Kashimi në anën e vetë serverit Zabbix është:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Le të shqyrtojmë ato më në detaje.
ConfigurationCache
Ky Ă«shtĂ« kashimi kryesor, nĂ« tĂ« cilin ruajmĂ« metrikat, hostet, elementĂ«t e tĂ« dhĂ«nave, triggerat â gjithçka qĂ« nevojitet pĂ«r ParapĂ«rpunimin dhe pĂ«r mbledhjen e tĂ« dhĂ«nave.
Të gjitha këto ruhen në ConfigurationCache, për të mos krijuar kërkesa të tepërta në DB. Pas fillimit të serverit, ne përditësojmë këtë cache, krijojmë dhe përditësojmë periodikisht konfigurimet.
Mbledhja e të dhënave
Schema është mjaft e madhe, por kryesore në të është grumbulluesit. Këto janë procese të ndryshme të grumbullimit. Ato janë përgjegjëse për lloje të ndryshme grumbullimi: grumbullojnë të dhëna për SNMP, IPMI, dhe i dërgojnë të gjitha në PreProcessing.
Grumbulluesit janë të rrethuar nga një vijë portokalli.
Në Zabbix ka elemente të dhënash agreguese të llogaritura, të cilat janë të nevojshme për të agreguar verifikimet. Nëse i kemi, ne i marrim të dhënat për to drejtpërdrejt nga ValueCache.
HistoriCache e PreProcessing
Të gjithë grumbulluesit përdorin ConfigurationCache për të marrë detyrat. Më pas, ato i kalojnë në PreProcessing.
PreProcessing përdor ConfigurationCache për të marrë hapat e PreProcessing. Ai i përpunon këto të dhëna në mënyra të ndryshme.
Pas pĂ«rpunimit tĂ« tĂ« dhĂ«nave me ndihmĂ«n e PreProcessing, ne i ruajmĂ« ato nĂ« HistoryCache pĂ«r t'i pĂ«rpunuar. KĂ«tu mbyllet grumbullimi i tĂ« dhĂ«nave dhe ne kalojmĂ« nĂ« procesin kryesor nĂ« Zabbix â history syncer, pasi kjo Ă«shtĂ« njĂ« arkitekturĂ« monolitike.
Shënim: PreProcessimi është një operacion mjaft i rëndë. Me versionin 4.2, ai është transferuar në proxy. Nëse keni një Zabbix shumë të madh me një numër të madh të elementeve të dhënash dhe frekuencë mbledhjeje, kjo e lehtëson shumë punën.
ValueCache, historia & trendet cache
History syncer është procesi kryesor që trajton në mënyrë atomike çdo element të dhënash, pra çdo vlerë.
History syncer merr vlerat nga HistoryCache dhe kontrollon në Configuration për praninë e triggerave për kalkulime. Nëse i ka, ai i kalkulon.
History syncer krijon një ngjarje, një eskalacion, për të krijuar njoftime nëse kërkohet sipas konfigurimit dhe regjistron. Nëse ka triggera për përpunim të mëtejshëm, ai këtë vlerë e mban mend në ValueCache, në mënyrë që të mos kërkohet në tabelën e historisë. Kështu, ValueCache mbushet me të dhënat që janë të nevojshme për kalkulimin e triggerave dhe elementeve të kalkuluara.
History syncer regjistron të gjitha të dhënat në DB, dhe ajo në disk. Procesi i përpunimit përfundohet këtu.
Kashimi në DB
Në anën e DB-së ka një sërë cachesh, kur dëshironi të shikoni grafika ose raporte për ngjarje:
Innodb_buffer_poolnë anën e MySQL;shared_buffersnë anën e PostgreSQL;effective_cache_sizenë anën e Oracle;shared_poolnë anën e DB2.
Ka shumë keƥa të tjera, por këto janë kryesore për të gjitha DB-të. Ato lejojnë mbajtjen në memorien operative të të dhënave që shpesh nevojiten për kërkesa. Kanë teknologjitë e tyre për këtë.
Performanca e DB-së është kritikisht e rëndësishme
Serveri Zabbix vazhdon të mbledhë të dhëna dhe t'i regjistrojë ato. Kur restartohet, lexon gjithashtu nga historia për të mbushur ValueCache. Përdor script dhe raporte Zabbix API, i ndërtuar mbi bazën e ndërfaqes Web. Zabbix API bën kërkesa në bazën e të dhënave dhe merr të dhënat e nevojshme për grafiku, raportet, listat e ngjarjeve dhe problemet e fundit.
PĂ«r vizualizimin â Grafana. NdĂ«r pĂ«rdoruesit tanĂ«, kjo Ă«shtĂ« njĂ« zgjidhje e popullarizuar. Ajo mund tĂ« dĂ«rgojĂ« kĂ«rkesa drejtpĂ«rdrejt pĂ«rmes Zabbix API dhe nĂ« DB, dhe krijon njĂ« konkurrencĂ« tĂ« caktuar pĂ«r marrjen e tĂ« dhĂ«nave. Prandaj, nevojitet njĂ« konfigurim mĂ« delikat dhe mĂ« i mirĂ« i DB-sĂ« pĂ«r t'u pĂ«rputhur me lĂ«shimin e shpejtĂ« tĂ« rezultateve dhe testimeve.
Housekeeper
Thirrja e tretĂ« pĂ«r performancĂ«n nĂ« Zabbix Ă«shtĂ« pastrimi i historisĂ« me ndihmĂ«n e Housekeeper. Ai respekton tĂ« gjitha konfigurimet â nĂ« elementet e tĂ« dhĂ«nave Ă«shtĂ« e caktuar se sa tĂ« mbahen dinamika e ndryshimeve (trendet) nĂ« ditĂ«.
TrendsCache e kalkulojmë në kohë reale. Kur vijnë të dhënat, ne i aggregojmë ato për një orë dhe i regjistrojmë në tabela për ndjekjen e ndryshimeve të trendeve.
Housekeeper fillon dhe eliminon informacionin nga DB me «select»-et e zakonshme. Kjo nuk është gjithmonë efikase, gjë që mund të kuptohet nga grafikët e performancës së proceseve të brendshme.
Grafiku i kuq tregon se History syncer është gjithmonë i angazhuar. Grafiku portokalli lart është Housekeeper-i, i cili nis vazhdimisht. Ai pret nga DB, që të fshijë të gjitha rreshtat që ka kërkuar.
Kur duhet të çaktivizohet Housekeeper? Për shembull, ka «Item ID» dhe duhet të fshihen 5,000 rreshta të fundit për një periudhë të caktuar. Sigurisht, kjo ndodhe nëpërmjet indekseve. Por zakonisht dataset është shumë i madh, dhe DB akoma e lexon nga disku dhe e ngre në cache. Kjo është gjithmonë një operacion shumë i shtrenjtë për DB-në dhe, në varësi të madhësisë së bazës, mund të çojë në probleme performancës.
Housekeeper mund tĂ« çaktivizohet thjesht. NĂ« ndĂ«rfaqen web ka njĂ« cilĂ«sim nĂ« «Administration general» pĂ«r Housekeeper. ĂaktivizojmĂ« housekeeping-un e brendshĂ«m pĂ«r historinĂ« e brendshme tĂ« trendeve dhe ai mĂ« nuk e menaxhon atĂ«.
ShtĂ«pia e punonjĂ«sve Ă«shtĂ« çaktivizuar, grafikĂ«t janĂ« rregulluar â çfarĂ« probleme mund tĂ« krijohen nĂ« kĂ«tĂ« rast dhe çfarĂ« mund tĂ« ndihmojĂ« nĂ« zgjidhjen e tretĂ« tĂ« performancĂ«s?
Ndara â seksionimi ose ndarja
Zakonisht ndarja konfigurohet nĂ« mĂ«nyra tĂ« ndryshme nĂ« çdo DB relacional qĂ« kam pĂ«rmendur. Ădo njĂ« ka teknologjinĂ« e saj, por ato janĂ« tĂ« ngjashme nĂ« pĂ«rgjithĂ«si. Krijimi i njĂ« ndarjeje tĂ« re shpesh shkakton probleme tĂ« caktuara.
Zakonisht, ndarjet pĂ«rshtaten nĂ« varĂ«si tĂ« 'setup'-it â sasisĂ« sĂ« tĂ« dhĂ«nave qĂ« krijohen nĂ« njĂ« ditĂ«. Si rregull, Ndarja jepet pĂ«r njĂ« ditĂ«, kjo Ă«shtĂ« minimumi. PĂ«r trendet e ndarjes sĂ« re â pĂ«r 1 muaj.
Vlerat mund tĂ« ndryshojnĂ« nĂ« rastin e njĂ« 'setup'-i shumĂ« tĂ« madh. NĂ«se 'setup'-i i vogĂ«l Ă«shtĂ« deri nĂ« 5,000 nvps (vlera tĂ« reja pĂ«r sekondĂ«), mesatarja â nga 5,000 deri nĂ« 25,000, ndersa e madhe â mbi 25,000 nvps. KĂ«to janĂ« instalime tĂ« mĂ«dha dhe shumĂ« tĂ« mĂ«dha qĂ« kĂ«rkojnĂ« njĂ« konfigurim tĂ« kujdesshĂ«m tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave.
Në instalime shumë të mëdha, prerja në një ditë mund të mos jetë optimale. Kam parë në MySQL ndarje prej 40 GB ose më shumë për një ditë. Ky është një volum shumë i madh të dhënash, i cili mund të shkaktojë probleme dhe duhet të reduktohet.
ĂfarĂ« ofron Ndarja?
Sekcionimi i tabelave. Shpesh kĂ«to janĂ« skedarĂ« tĂ« veçantĂ« nĂ« disk. Plani i pyetjeve zgjidh mĂ« optimal njĂ« ndarje. NĂ« pĂ«rgjithĂ«si, ndarja pĂ«rdoret sipas intervalit â kjo Ă«shtĂ« e vĂ«rtetĂ« edhe pĂ«r Zabbix. Ne e pĂ«rdorim "timestamp" â koha nga fillimi i epokĂ«s. KĂ«tu janĂ« numra tĂ« zakonshĂ«m. Ju pĂ«rcaktoni fillimin dhe fundin e ditĂ«s â kjo Ă«shtĂ« njĂ« ndarje.
Fshirja e shpejtĂ« â DELETE. Zgjedhet njĂ« skedar/subtabelĂ«, dhe jo njĂ« grumbull rreshtash pĂ«r t'u fshirĂ«.
E ndjeshme pĂ«rshpejton marrjen e tĂ« dhĂ«nave SELECT â pĂ«rdor njĂ« ose mĂ« shumĂ« ndarje, dhe jo tĂ« gjithĂ« tabelĂ«n. NĂ«se kĂ«rkoni tĂ« dhĂ«na nga dy ditĂ« mĂ« parĂ«, ato zgjidhen nga DB mĂ« shpejt, sepse duhet tĂ« ngarkohet nĂ« cache dhe tĂ« jepet vetĂ«m njĂ« skedar, dhe jo njĂ« tabelĂ« tĂ« madhe.
Shpesh, shumĂ« DB gjithashtu pĂ«rshpejton INSERT â insertimin nĂ« tabelĂ«n fĂ«mijĂ«.
TimescaleDB
Për v 4.2 ne kemi vënë re TimescaleDB. Ky është një shtesë për PostgreSQL me një ndërfaqe natyrore. Shtesa punon efektiv me të dhënat e serive të kohës, pa humbur përparësitë e bazave të të dhënave relacionale. TimescaleDB gjithashtu automatizon particionimin.
NĂ« TimescaleDB, ka njĂ« koncept hipertable (hipertable), tĂ« cilin ju krijoni. NĂ« tĂ« ndodhen çanka â partitĂ«. Ăankat janĂ« fragmente tĂ« menaxhuara automatikisht tĂ« hipertabelĂ«s, qĂ« nuk ndikojnĂ« nĂ« fragmentet e tjera. PĂ«r çdo çank ka njĂ« interval tĂ« tij tĂ« kohĂ«s.
TimescaleDB vs PostgreSQL
TimescaleDB punon vërtet në mënyrë efektive. Prodhuesit e shtesës thonë se ata përdorin algoritmin më të saktë për përpunimin e kërkesave, veçanërisht për <code>inserts</code>. Kur madhësitë e dataset-ve rriten, algoritmi mban performancën konstante.
Pas 200 milion rreshtash, PostgreSQL zakonisht fillon të bjerë ndjeshëm dhe humb performancën deri në 0. TimescaleDB mundëson inserte efikase pavarësisht nga sasia e të dhënave.
Instalimi
Instalimi i TimescaleDB Ă«shtĂ« mjaft i thjeshtĂ« pĂ«r çdo paketĂ«. NĂ« pĂ«rshkruhet nĂ« detaj â ai varet nga paketat zyrtare tĂ« PostgreSQL. TimescaleDB gjithashtu mund tĂ« ndĂ«rtosh dhe kompilohet manualisht.
Për DB-në Zabbix thjesht aktivizojmë zgjerimin:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix Ju aktivizoni zgjerimin dhe e krijoni atë për DB-në Zabbix. Hapi i fundit është krijimi i hipertabelës.
Migrimi i tabelave të historisë në TimescaleDB
Për këtë ka një funksion të veçantë 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 Funksioni ka tre parametra. I pari â tabela nĂ« DB, pĂ«r tĂ« cilĂ«n duhet tĂ« krijoni hipertabelĂ«n. I dyti â fusha, sipas tĂ« cilit duhet tĂ« krijoni chunk_time_interval â intervali i chunk-Ă«ve tĂ« particionit qĂ« duhet tĂ« pĂ«rdoren. NĂ« rastin tim, intervali Ă«shtĂ« njĂ« ditĂ« â 86,400.
Parametri i tretĂ« â migroni_tĂ«_dhenave. NĂ«se vendoset e vĂ«rtetĂ«, atĂ«herĂ« tĂ« gjitha tĂ« dhĂ«nat aktuale transferohen nĂ« pjesĂ« tĂ« krijuara paraprakisht. UnĂ« vetĂ« e pĂ«rdora migroni_tĂ«_dhenave. Kisha rreth 1 TB, qĂ« zuri mĂ« shumĂ« se njĂ« orĂ«. Edhe nĂ« disa raste gjatĂ« testimit fshija tĂ« dhĂ«nat historike tĂ« llojeve simbolike qĂ« nuk ishin tĂ« nevojshme pĂ«r ruajtje, qĂ« tĂ« mos i transferoja ato.
Hapi i fundit â UPDATE: nĂ« db_extension vendosim timescaledb, pĂ«r tĂ« ndihmuar DB-nĂ« tĂ« kuptojĂ« se ekziston kjo zgjerim. Zabbix e aktivizon atĂ« dhe e pĂ«rdor saktĂ« sintaksĂ«n dhe kĂ«rkesat ndaj DB-sĂ« â ato funksionalitete qĂ« janĂ« tĂ« nevojshme pĂ«r TimescaleDB.
Konfigurimi i harduerit
UnĂ« pĂ«rdora dy servera. I pari â makina VMware. Ajo Ă«shtĂ« mjaft e vogĂ«l: 20 procesorĂ« IntelÂź XeonÂź CPU E5-2630 v 4 @ 2.20GHz, 16 GB RAM dhe njĂ« SSD prej 200 GB.
Unë instalova PostgreSQL 10.8 me OS Debian 10.8-1.pgdg90+1 dhe sistemin e skedave xfs. E gjitha u konfigurova minimalisht për të përdorur pikërisht këtë bazë të dhënash, përveç asaj që do të përdorë vetë Zabbix.
Në këtë makinë ishte serveri Zabbix, PostgreSQL dhe agensit e ngarkesës. Kisha 50 agjentë aktivë që përdornin LoadableModule, për të gjeneruar shumë shpejt rezultate të ndryshme: numra, këngë. Unë mbusha bazën me një sasi të madhe të dhënash.
Fillimi konfigurimi përmbante 5,000 elemente të dhënash për çdo host. Pothuajse çdo element kishte një nxitës, për t'u ngjashëm me instalimet reale. Në disa raste kishte më shumë se një nxitës. Për çdo nyje të rrjetit për 3,000-7,000 nxitës.
Intervali i përditësimit të elementeve të dhënash është 4-7 sekonda. Ngarkesën e rregullova duke përdorur jo vetëm 50 agjentë, por duke shtuar edhe më shumë. Gjithashtu, me anë të elementeve të dhënash kam rregulluar dinamikisht ngarkesën dhe e kam ulur intervalin e përditësimit në 4 sekonda.
PostgreSQL. 35,000 nvps
Shtimi i parĂ« nĂ« kĂ«tĂ« harduer e kam pasur nĂ« PostgreSQL tĂ« pastĂ«r â 35,000 vlera nĂ« sekondĂ«. Siç duket, futja e tĂ« dhĂ«nave zĂ« fraksione sekondash â gjithçka Ă«shtĂ« nĂ« rregull dhe e shpejtĂ«. E vetmja gjĂ«, disku SSD me kapacitet 200 GB mbushet shpejt.
Ky Ă«shtĂ« dashboard-i standard i performancĂ«s sĂ« Zabbix-it â serverave.
Grafiku i parĂ« blu â numri i vlerave nĂ« sekondĂ«. Grafiku i dytĂ« nĂ« tĂ« djathtĂ« â ngarkesa e proceseve tĂ« ndĂ«rtimit. TretĂ« â ngarkesa e proceseve tĂ« brendshme tĂ« ndĂ«rtimit: history syncers dhe Housekeeper, i cili kĂ«tu u ekzekutua pĂ«r njĂ« kohĂ« tĂ« mjaftueshme.
Grafiku i katĂ«rt tregon pĂ«rdorimin e HistoryCache. Ky Ă«shtĂ« njĂ« tampon para se tĂ« futen nĂ« bazĂ«n e tĂ« dhĂ«nave. Grafiku i gjelbĂ«r i pestĂ« tregon pĂ«rdorimin e ValueCache, qĂ« do tĂ« thotĂ« se sa hit-e ka ValueCache pĂ«r trigger-at â disa mijĂ«ra vlera nĂ« sekondĂ«.
PostgreSQL. 50,000 nvps
Më pas e rita ngarkesën në 50,000 vlera në sekondë në të njëjtën pajisje.
Gjatë ngarkesës me Housekeeper, futja e 10,000 vlerave u regjistrua për 2-3 sekonda.
Housekeeper tashmë fillon të pengojë punën.
NĂ« grafikun e tretĂ«, duket se ngarkesa e trapper-ve dhe history syncers-ve Ă«shtĂ« ende nĂ« nivelin 60%. NĂ« grafikun e katĂ«rt, HistoryCache gjatĂ« punĂ«s sĂ« Housekeeper-it fillon tĂ« mbushet mjaft aktivisht. Ai u mbush nĂ« 20% â kjo Ă«shtĂ« rreth 0,5 GB.
PostgreSQL. 80,000 nvps
Më pas e rita ngarkesën në 80,000 vlera në sekondë. Kjo është rreth 400,000 elemente të dhënash dhe 280,000 trigger-a.
Futja me ngarkesën e tridhjetë history syncers-ve është tashmë mjaft e lartë.
Gjithashtu kam rritur parametra të ndryshëm: history syncers, cache.
NĂ« pajisjen time, ngarkesa e history syncers-ve u rrit nĂ« maksimum. HistoryCache u mbush shpejt me tĂ« dhĂ«na â u grumbulluan tĂ« dhĂ«na pĂ«r procesim nĂ« tampon.
Gjatë gjithë kësaj kohe kam vëzhguar si përdoren procesori, memoria operative dhe parametrat e tjerë të sistemit, dhe zbuloj se shfrytëzimi i disqeve ka qenë maksimal.
Arrita të përdor kapacitetet maksimale të diskut në këtë harduer dhe në këtë makinë virtuale. Me një intensitet të tillë, PostgreSQL filloi të hidhej të dhënat mjaft aktivisht, dhe disku nuk arrinte më të punonte për shkrim dhe lexim.
Serveri i dytë
Mora një server tjetër, i cili kishte tashmë 48 procesorë dhe 128 GB memorie operative. E rregullova atë - vendosa 60 history syncer, dhe arrita një performancë të pranueshme.
Në fakt, kjo është tashmë kufiri i performancës, ku është e nevojshme të ndërmirren diçka.
TimescaleDB. 80,000 nvps
Detyra ime kryesore është të kontrolloj kapacitetet e TimescaleDB nga ngarkesa Zabbix. 80 mijë vlera në sekondë - është shumë, frekuenca e mbledhjes së metrikave (përveç Yandex, sigurisht) dhe një 'setup' mjaft i madh.
Në çdo grafik ka një rënie - kjo është pikërisht migrimi i të dhënave. Pasi rëniet në serverin Zabbix, profili i ngarkesës history syncer ka ndryshuar shumë - ra në tre herë.
TimescaleDB lejon të futen të dhëna praktikisht deri në 3 herë më shpejt dhe përdor më pak HistoryCache.
Prandaj, ju do të ofrohen të dhëna në kohë.
TimescaleDB. 120,000 nvps.
Pastaj e zgjata numrin e elementeve tĂ« dhĂ«nash deri nĂ« 500,000. QĂ«llimi kryesor ishte tĂ« verifikoja kapacitetet e TimescaleDB â kam arritur njĂ« vlerĂ«sim prej 125,000 vlerash nĂ« sekondĂ«.
Ky është një 'setup' funksional, i cili mund të operojë gjatë për një kohë të gjatë. Por pasi disku im ishte vetëm 1.5 TB, e mbusha atë për disa ditë.
Më e rëndësishmja, në të njëjtën kohë u krijuan parti të reja në TimescaleDB.
Për performancën, kjo është krejtësisht e padukshme. Kur krijohen parti në MySQL, për shembull, gjithçka është ndryshe. Zakonisht ndodh natën, sepse bllokon injektimin e përgjithshëm, punën me tabelat dhe mund të shkaktojë degradim të shërbimit. Në rastin e TimescaleDB, kjo nuk ndodh.
Si shembull do të tregoj një grafik nga shumica në community. Në imazh është përfshirë TimescaleDB, falë të cilit ngarkesa mbi përdorimin e io.weight në procesor ra. Përdorimi i elementeve të proceseve të brendshme gjithashtu ra. Dhe kjo është një makinë virtuale normale me disqe normale, jo SSD.
PĂ«rfundimet
TimescaleDB është një zgjidhje e mirë për 'setup' të vogla., të cilat ndihmojnë performancën e diskut. Ajo do t'ju lejojë të vazhdoni të punoni deri në migrimin e DB-së në një harduer më të shpejtë.
TimescaleDB është i lehtë për t'u konfiguruar, ofron një rritje të performancës, dhe punon mirë me Zabbix dhe ka përparësi krahasuar me PostgreSQL.
Nëse përdorni PostgreSQL dhe nuk planifikoni ta ndryshoni, rekomandoj të përdorni PostgreSQL me zgjerimin TimescaleDB në kombinim me Zabbix. Ky zgjidhje funksionon efikasisht deri në setup-et mesatare.
Kur themi 'performancĂ« e lartĂ«' â nĂ«nkuptojmĂ« . Nuk do tĂ« duhet tĂ« prisni shumĂ« pĂ«r tĂ« njohur teknologjitĂ« dhe praktikat qĂ« lejojnĂ« shĂ«rbimet tĂ« shĂ«rbejnĂ« miliona pĂ«rdorues. Lista pĂ«r 7 dhe 8 nĂ«ntor e kemi pĂ«rgatitur, ndĂ«rsa mund tĂ« ofrohen akoma.
Abonohuni në grupin tonë në Facebook dhe , në të cilat zbulojmë karakteristikat e konferencës së ardhshme, dhe mësoni se si të nxirrni maksimumin nga ajo.
Burimi: habr.com
