Zabbix është një sistem monitorimi. Si çdo sistem tjetër, ai përballet me tre probleme kryesore të çdo sistemi monitorimi: mbledhjen dhe përpunimin e të dhënave, ruajtjen e historisë dhe pastrimin e saj.
Etapet e marrjes, përpunimit dhe regjistrimit të të dhënave marrin kohë. Pak, por për një sistem të madh, kjo mund të rezultojë në vonesa të mëdha. Problemi i ruajtjes është një çështje e qasjes në të dhëna. Ato përdoren për raportet, verifikimet dhe trigger-at. Vonesat në qasjen në të dhëna gjithashtu ndikojnë në performancë. Kur DB-të rriten, të dhënat joaktuale duhet të fshihen. Fshirja është një operacion i rëndë, i cili gjithashtu konsumon një pjesë të burimeve.
Problemet e vonesave gjatĂ« mbledhjes dhe ruajtjes nĂ« Zabbix zgjidhen me ndihmĂ«n e caching: disa lloje cache, caching nĂ« DB. PĂ«r tĂ« zgjidhur problemin e tretĂ«, caching nuk Ă«shtĂ« i pĂ«rshtatshĂ«m, prandaj nĂ« Zabbix Ă«shtĂ« pĂ«rdorur TimescaleDB. PĂ«r kĂ«tĂ« do tĂ« flasĂ« Andrei Gushchin â inxhinier i mbĂ«shtetjes teknike . Andrei ka mĂ« shumĂ« se 6 vite nĂ« mbĂ«shtetje tĂ« Zabbix dhe pĂ«rballĂ«t drejtpĂ«rdrejt me performancĂ«n.
Si funksionon TimescaleDB, çfarë performancë mund të japë krahasuar me PostgreSQL-në e zakonshme? Cila është roli i Zabbix për DB-në e TimescaleDB? Si të fillosh nga fillimi dhe si të migrosh nga PostgreSQL dhe cilat janë konfigurimet më të mira për performancë? Për gjithë këtë më poshtë.
Sfidat e Performancës
Ădo sistem monitorimi pĂ«rballet me sfida tĂ« caktuara tĂ« performancĂ«s. UnĂ« do tĂ« flas pĂ«r tre prej tyre: mbledhja dhe pĂ«rpunimi i tĂ« dhĂ«nave, ruajtja, pastrimi i historisĂ«.
Mbledhja dhe pĂ«rpunimi i tĂ« dhĂ«nave tĂ« shpejta. NjĂ« sistem i mirĂ« monitorimi duhet tĂ« marrĂ« tĂ« dhĂ«nat e gjitha dhe t'i pĂ«rpunojĂ« ato sipas shprehjeve trigger â sipas kritereve tĂ« tij. Pas pĂ«rpunimit, sistemi duhet gjithashtu ta ruajĂ« shpejt kĂ«to tĂ« dhĂ«na nĂ« DB, nĂ« mĂ«nyrĂ« qĂ« tĂ« pĂ«rdoren mĂ« vonĂ«.
Ruajtja e historisë. Një sistem i mirë monitorimi duhet të ruajë historinë në DB dhe të ofrojë qasje të lehtë në metrika. Historia është e nevojshme për ta përdorur atë në raporte, grafikë, trigger-a, vlera prag dhe elementë të dhënash të llogaritur për njoftime.
Pastrimi i historisĂ«. NdonjĂ«herĂ« vjen njĂ« ditĂ« kur nuk keni nevojĂ« tĂ« mbani metrikat. Pse ju nevojiten tĂ« dhĂ«na tĂ« mbledhura 5 vite mĂ« parĂ«, njĂ« muaj apo dy: disa nyje janĂ« fshirĂ«, disa hoste apo metrika tashmĂ« sâkanĂ« nevojĂ«, sepse janĂ« vjetruar dhe kanĂ« pushuar sĂ« u mbledhur. NjĂ« sistem monitorimi i mirĂ« duhet tĂ« ruajĂ« tĂ« dhĂ«na historike dhe kohĂ« pas kohe t'i fshijĂ« ato, pĂ«r tĂ« mos e mbingarkuar bazĂ«n e tĂ« dhĂ«nave.
Pastrimi i të dhënave të vjetruara është një çështje e ndjeshme, që ndikon shumë në performancën e bazës së të dhënave.
Keshimi në Zabbix
NĂ« Zabbix, thirrjet e para dhe tĂ« dyta zgjidhen me anĂ« tĂ« keshimit. PĂ«r mbledhjen dhe pĂ«rpunimin e tĂ« dhĂ«nave pĂ«rdoret memoria operative. PĂ«r ruajtje â historitĂ« nĂ« triggera, grafika dhe elemente tĂ« dhĂ«nash tĂ« llogaritura. NĂ« anĂ«n e BazĂ«s sĂ« tĂ« DhĂ«nave ka njĂ« keshim tĂ« caktuar pĂ«r zgjedhjet kryesore, pĂ«r shembull, grafikat.
Keshimi në anën e vetë serverit Zabbix është:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Le të flasim për to në detaje.
ConfigurationCache
Ky Ă«shtĂ« keshimi kryesor, ku ruhen metrikat, hostet, elementet e tĂ« dhĂ«nave, triggerat â gjithçka qĂ« nevojitet pĂ«r ParapĂ«rpunimin dhe mbledhjen e tĂ« dhĂ«nave.
Të gjitha këto ruhen në ConfigurationCache, për të mos krijuar kërkesa të panevojshme në Bazën e të Dhënave. Pas nisjes së serverit, ne përditësojmë këtë kesh, krijojmë dhe përditësojmë periodikisht konfigurimet.
Grumbullimi i të dhënave
Schema është mjaft e madhe, por e rëndësishme është mbledhësit. Këta janë procese të ndryshme mbledhjeje. Ata janë përgjegjës për lloje të ndryshme mbledhjeje: mbledhin të dhëna nëpërmjet SNMP, IPMI dhe i dërgojnë ato në Parapërpunim.
Mbledhësit janë të përshkuar me një vijë portokalli.
Në Zabbix ka elemente të dhënash të llogaritura agregat, që nevojiten për të agreguar kontrollet. Nëse i kemi, i marrim të dhënat për to drejtpërdrejt nga ValueCache.
PreProcessing HistoryCache
Të gjithë mbledhësit përdorin ConfigurationCache për të marrë detyra. Më pas, ata i dërgojnë ato në Parapërpunim.
Parapërpunimi përdor ConfigurationCache për të marrë hapat e Parapërpunimit. 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 ParapĂ«rpunimit, i ruajmĂ« ato nĂ« HistoryCache pĂ«r tâi pĂ«rpunuar. KĂ«tu pĂ«rfundon mbledhja e tĂ« dhĂ«nave dhe kalojmĂ« nĂ« procesin kryesor nĂ« Zabbix â history syncer, pasi kjo Ă«shtĂ« njĂ« arkitekturĂ« monolite.
Shënim: Parapërpunimi është një operacion mjaft i rëndë. Me versionin 4.2 është nxjerrë në proxy. Nëse keni një Zabbix shumë të madh me shumë elemente të dhënash dhe frekuencë mbledhjeje, kjo shumë lehtëson punën.
ValueCache, cache për histori & tendenca
History syncer është procesi kryesor që përpunon çdo element të dhënash në mënyrë atomike, domethënë çdo vlerë.
History syncer merr vlerat nga HistoryCache dhe kontrollon në Configuration nëse ka shkaktarë për llogaritjet. Nëse ka, ai i llogarit.
History syncer krijon një ngjarje, një eskalim, për të krijuar njoftime, nëse kërkohet sipas konfigurimit, dhe e regjistron. Nëse ka shkaktarë për përpunim të mëtejshëm, ajo vlerë e ruan në ValueCache, në mënyrë që të mos shkonte në tabelën e historisë. Kështu ValueCache mbushet me të dhëna të nevojshme për llogaritjen e shkaktarëve dhe elementeve të llogaritura.
History syncer regjistron tĂ« gjitha tĂ« dhĂ«nat nĂ« DB, dhe ajo â nĂ« disk. Procesi i pĂ«rpunimit pĂ«rfundon kĂ«tu.
Keshimi në DB
Në anën e DB-së ka cache të ndryshme kur dëshiron të shikosh grafikat ose raportet mbi ngjarjet:
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ë caches të tjera, por këto janë kryesore për të gjitha DB-të. Ato lejojnë që të mbash të dhënat në memorie që shpesh nevojiten për kërkesa. Ato kanë teknologji të veta për këtë.
Performanca e DB-së është kritike
Zabbix serveri vazhdimisht mbledh të dhëna dhe i regjistron ato. Kur rivendoset, ai gjithashtu lexon nga historia për të mbushur ValueCache. Skriptet dhe raportet përdorin Zabbix API, i cili është ndërtuar mbi bazën e ndërfaqes Web. Zabbix API i qaset bazës së të dhënave dhe merr të dhënat e nevojshme për grafikët, raportet, listat e ngjarjeve dhe problemet më të fundit.
PĂ«r vizualizimin â NĂ«se tashmĂ« e dini se çfarĂ« Ă«shtĂ« analiza e grupeve dhe se si ta bĂ«ni nĂ« SQL, kaloni menjĂ«herĂ« nĂ« seksionin e fundit.. NdĂ«r pĂ«rdoruesit tanĂ«, ky Ă«shtĂ« njĂ« zgjidhje popullore. Ai di tĂ« dĂ«rgojĂ« direkt kĂ«rkesa pĂ«rmes Zabbix API nĂ« DB dhe krijon njĂ« konkurrencĂ« tĂ« caktuar pĂ«r marrjen e tĂ« dhĂ«nave. Prandaj nevojitet njĂ« konfigurim mĂ« i hollĂ«sishĂ«m dhe mĂ« i mirĂ« i DB-sĂ« pĂ«r t'iu pĂ«rgjigjur shpejt rezultatĂ«ve dhe testimeve.
Housekeeper
Thirrja e tretĂ« e performancĂ«s nĂ« Zabbix Ă«shtĂ« pastrimi i historisĂ« me anĂ« tĂ« Housekeeper. Ai respekton tĂ« gjitha konfigurimet â nĂ« elementĂ«t e tĂ« dhĂ«nave Ă«shtĂ« treguar se sa tĂ« ruhet dinamika e ndryshimeve (trendĂ«t) nĂ« ditĂ«.
TrendsCache llogaritet në fluks. Kur vijnë të dhënat, ne i agregojmë ato për një orë dhe i regjistrojmë në tabelat për dinamiken e ndryshimeve të trendëve.
Housekeeper aktivizohet dhe fshin informacionin nga DB me "selects" të zakonshme. Kjo nuk është gjithmonë efektive, gjë që mund të kuptohet nga grafikët e performancës së proceseve të brendshme.
Grafiku i kuq tregon se History syncer është vazhdimisht i zënë. Grafiku portokalli lart është Housekeeper, i cili aktivizohet vazhdimisht. Ai pret që DB të fshijë të gjitha rreshtat që ai ka përcaktuar.
Kur duhet të çaktivizohet Housekeeper? Për shembull, nëse ka një «Item ID» dhe duhet të fshihen 5 mijë rreshta në një kohë të caktuar. Natyrisht, kjo ndodh përmes indekseve. Por zakonisht dataset është shumë i madh, dhe DB gjithsesi lexon nga disku dhe e ngre në cache. Kjo gjithmonë është një operacion shumë i shtrenjtë për DB dhe, në varësi të madhësive të bazës, mund të shkaktojë probleme në performancë.
Housekeeper mund të çaktivizohet lehtësisht. Në ndërfaqen Web ka një cilësim në «Administration general» për Housekeeper. Ne e çaktivizojmë Housekeeping-un e brendshëm për historinë e brendshme të trendeve dhe ai nuk menaxhon më këtë.
Housekeeper u çaktivizua, grafiket u rregulluan - çfarë probleme të mundshme mund të ketë në këtë rast dhe çfarë mund të ndihmojë në zgjidhjen e thirrjes së tretë për performancën?
Partitioning - seksionimi ose parcellimi
Zakonisht, parcellimi konfigurimi bĂ«het 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Ă« seksioni tĂ« ri shpesh shkakton probleme tĂ« caktuara.
Zakonisht, seksionet konfigurohen në varësi të «setup-it» - numrit të të dhënave që gjenerohen në një ditë. Zakonisht, Partitioning-u vendoset për një ditë, kjo është minimumi. Për trendet, seksione të reja - për 1 muaj.
Vlerat mund të ndryshojnë në rastin e një «setup» shumë të madh. Nëse «setup» i vogël është deri në 5,000 nvps (vlera të reja për sekondë), mesatarja - nga 5,000 deri në 25,000, atëherë e madhe - mbi 25,000 nvps. Këto janë instalime të mëdha dhe shumë të mëdha që kërkojnë konfigurim të kujdesshëm të bazës së të dhënave.
Në instalime shumë të mëdha, një segment në një ditë mund të mos jetë optimal. Kam parë në MySQL seksione mbi 40 GB dhe më shumë për ditë. Ky është një volum shumë i madh të dhënash, që mund të shkaktojë probleme dhe duhet të reduktohet.
ĂfarĂ« ofron Partitioning?
Seksionimi i tabelave. Zakonisht, këto janë skedarë të veçantë në disk. Plani i kërkesave zgjidh më optimal një seksion. Zakonisht, parcellimi përdoret sipas intervaleve - kjo është e vërtetë edhe për Zabbix. Ne përdorim atje «timestamp» - koha që nga fillimi i epokës. Këtu kemi numra të zakonshëm. Ju konfiguroni fillimin dhe fundin e ditës - kjo është një seksion.
Fshirje e shpejtĂ« â FSHIZgjedhet njĂ« skedar/subtabela, e jo njĂ« grumbull rreshtash pĂ«r t'u fshirĂ«.
Duket se pĂ«rshpejton marrjen e tĂ« dhĂ«nave. SELECT â pĂ«rdor njĂ« ose mĂ« shumĂ« pjesĂ«, dhe jo tĂ«rĂ« tabelĂ«n. NĂ«se i drejtoheni tĂ« dhĂ«nave tĂ« dy ditĂ«ve mĂ« parĂ«, ato zgjidhen nga DB mĂ« shpejt, sepse duhet tĂ« ngarkohen nĂ« cache dhe tĂ« jepen vetĂ«m njĂ« skedar, e jo njĂ« tabelĂ« tĂ« madhe.
Shpesh shumĂ« DB gjithashtu pĂ«rmirĂ«son. SHTO â inserimet nĂ« tabelĂ«n fĂ«mijĂ«.
TimescaleDB
Për v 4.2 ne u fokusuam në TimescaleDB. Ky është një zgjerim për PostgreSQL me një ndërfaqe natyrore. Zgjerimi punon efektivisht me të dhënat e serive kohore, pa humbur përfitimet e DB-ve rrelacionale. TimescaleDB gjithashtu partitizon automatikisht.
NĂ« TimescaleDB ekziston koncepti i hipertabelĂ«s (hypertable), tĂ« cilĂ«n e krijoni. Ajo pĂ«rmban skaje â pjesitĂ«. Skajat janĂ« fragmente tĂ« menaxhuara automatikisht tĂ« hipertabelĂ«s, tĂ« cilat nuk ndikojnĂ« nĂ« fragmente tĂ« tjera. PĂ«r çdo skaj ka njĂ« gamĂ« tĂ« veçantĂ« kohore.
TimescaleDB vs PostgreSQL
TimescaleDB funksionon vërtet efektivisht. Prodhuesit e zgjerimit pretendojnë se ata përdorin një algoritëm më të saktë për trajtimin e kërkesave, veçanërisht të inserts. Kur dimensionet e të dhënave që futen rriten, algoritmi mbështet një performancë të vazhdueshme.
Pas 200 milion rreshtash, PostgreSQL zakonisht fillon tĂ« ngadalĂ«sohet ndjeshĂ«m dhe humbet performancĂ«n deri nĂ« 0. TimescaleDB lejon efikasitetin nĂ« inserimet âinsertsâ me çdo sasi tĂ« dhĂ«nash.
Instalimi
TĂ« instalosh TimescaleDB Ă«shtĂ« mjaft e lehtĂ« pĂ«r çdo paketĂ«. NĂ« Ă«shtĂ« pĂ«rshkruar nĂ« detaje â varet nga paketat zyrtare tĂ« PostgreSQL. TimescaleDB mund tĂ« ndĂ«rtohet dhe kompilohet gjithashtu manualisht.
Për DB Zabbix thjesht aktivizojmë zgjerimin:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix Aktivizoni zgjerimin dhe krijoni atĂ« pĂ«r DB Zabbix. Hapi i fundit â 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Ă« krijohet hipertabela. TĂ« dytin â fushĂ«n, sipas tĂ« cilit duhet tĂ« krijohet chunk_time_interval â intervali i grumbujve tĂ« particioneve qĂ« duhet tĂ« pĂ«rdoren. NĂ« rastin tim, intervalu Ă«shtĂ« njĂ« ditĂ« â 86 400.
Parametri i tretĂ« â migroj tĂ« dhĂ«nat. NĂ«se vendoset true, tĂ« gjitha tĂ« dhĂ«nat aktuale transferohen nĂ« grumbujt e krijuar paraprakisht. UnĂ« vetĂ« kam pĂ«rdorur migroj tĂ« dhĂ«nat. Kishte rreth 1 TB, qĂ« zuri mĂ« shumĂ« se njĂ« orĂ«. Edhe nĂ« disa raste, gjatĂ« testimeve, kam fshirĂ« tĂ« dhĂ«nat historike simetrike qĂ« nuk ishin tĂ« nevojshme pĂ«r ruajtje, pĂ«r t'i shmangur ato.
Hapi i fundit â UPDATE: nĂ« db_extension vendosim timescaledb, pĂ«r t'i treguar DB-sĂ« se ka kĂ«tĂ« zgjerim. Zabbix e aktivizon atĂ« dhe e pĂ«rdor kĂ«tĂ« sintaksĂ« e kĂ«rkesa pĂ«r DB-nĂ« â ato veçori qĂ« janĂ« tĂ« nevojshme pĂ«r TimescaleDB.
Konfigurimi i harduerit
Kam pĂ«rdorur dy serverĂ«. I pari â VMware-makina. Ajo Ă«shtĂ« mjaft e vogĂ«l: 20 procesorĂ« IntelÂź XeonÂź CPU E5-2630 v 4 @ 2.20GHz, 16 GB memorie RAM dhe njĂ« disk SSD prej 200 GB.
Kam instaluar aty PostgreSQL 10.8 me OS Debian 10.8-1.pgdg90+1 dhe sistemin e skedarëve xfs. Të gjitha janë minimalisht konfigurur për të përdorur saktësisht 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 agjentët e ngarkesës. Kam pasur 50 agjentë aktivë, të cilat përdornin LoadableModule, për të gjeneruar shumë shpejt rezultatet e ndryshme: numra, stringa. E mbusha bazën me shumë të dhëna.
Fillimisht, konfigurimi përmbante 5 000 elemente të dhënash për çdo host. Gati çdo element përmbante një trigger, që të ishte e ngjashme me instalimet reale. Në disa raste kishte më shumë se një trigger. Në një nyje të rrjetit kishim 3 000-7 000 triggera..
Intervali i azhurnimit tĂ« elementeve tĂ« dhĂ«nash â 4-7 sekondaUnĂ« rregulloja ngarkesĂ«n duke pĂ«rdorur jo vetĂ«m 50 agjentĂ«, por shtoja edhe mĂ« shumĂ«. Po ashtu, me anĂ« tĂ« elementeve tĂ« dhĂ«nash, rregulloja dinamikisht ngarkesĂ«n dhe ulja e intervalit tĂ« rifreskimit nĂ« 4 sekonda.
PostgreSQL. 35,000 nvps
SĂ« pari, ndihesha nĂ« kĂ«tĂ« harduer me PostgreSQL tĂ« pastĂ«r â 35,000 vlera nĂ« sekondĂ«. Siç duket, futja e tĂ« dhĂ«nave merr fraksione sekonde â gjithçka Ă«shtĂ« mirĂ« dhe e shpejtĂ«. E vetmja gjĂ« Ă«shtĂ« se disku SSD prej 200 GB mbushet shpejt.
Ky Ă«shtĂ« dashboard-i standard i performancĂ«s Zabbix â tĂ« serverit.
Grafiku i parĂ« blu â numri i vlerave nĂ« sekondĂ«. Grafiku i dytĂ« nĂ« tĂ« djathtĂ« â ngarkesa e proceseve tĂ« ndĂ«rtimit. TretĂ«sori â ngarkesa e proceseve tĂ« brendshme tĂ« ndĂ«rtimit: history syncers dhe Housekeeper, i cili kĂ«tu u krye pĂ«r njĂ« kohĂ« tĂ« konsiderueshme.
Grafiku i katĂ«rt tregon pĂ«rdorimin e HistoryCache. Ky Ă«shtĂ« njĂ« tampon para futjes nĂ« DB. Grafiku i gjelbĂ«r i pestĂ« tregon pĂ«rdorimin e ValueCache, qĂ« do tĂ« thotĂ« sa goditje ka pasur ValueCache pĂ«r treguesit â kjo Ă«shtĂ« disa mijĂ«ra vlera nĂ« sekondĂ«.
PostgreSQL. 50,000 nvps
Në vazhdim, unë e rritja ngarkesën në 50,000 vlera në sekondë në këtë harduer të njëjtë.
Gjatë ngarkesës me Housekeeper, futja e 10,000 vlerave u regjistrua për 2-3 sekonda.
Housekeeper tashmë fillon të pengojë punën.
Nga grafiku i tretĂ« duket se, nĂ« kĂ«tĂ« moment, ngarkesa e trapper-ve dhe history syncers Ă«shtĂ« ende nĂ« nivelin 60%. NĂ« grafikun e katĂ«rt, HistoryCache gjatĂ« punĂ«s sĂ« Housekeeper tashmĂ« fillon tĂ« mbushet mjaft aktivisht. Ai Ă«shtĂ« mbushur nĂ« 20% â rreth 0.5 GB.
PostgreSQL. 80,000 nvps
Më pas, unë e rritja ngarkesën në 80,000 vlera në sekondë. Kjo është rreth 400,000 elemente të dhënash dhe 280,000 tregues.
Futja me ngarkesën e tridhjetë history syncers është tashmë mjaft e lartë.
Po ashtu, unë e rritesha disa parametra: history syncers, memorie cache.
NĂ« harduerin tim, ngarkesa e history syncers u rrit nĂ« maksimum. HistoryCache shpejt u mbush me tĂ« dhĂ«na â nĂ« tampon u grumbulluan tĂ« dhĂ«na pĂ«r trajtim.
Të gjithë këtë kohë kam monitoruar se si përdoret procesori, memoria RAM dhe parametrat e tjerë të sistemit, dhe zbulova se shfrytëzimi i disqeve ishte maksimal.
Arrita të përdor mundësitë maksimale të diskut në këtë harduer dhe në këtë makinë virtuale. Me një intensitet të tillë, PostgreSQL filloi të hidhte të dhëna mjaft aktivisht dhe disku tashmë nuk arrinte të punonte në regjistrimin dhe leximin.
Serveri i dytë
Kam mora një server tjetër që kishte tashmë 48 procesorë dhe 128 GB memorie RAM. E optimizova - instalova 60 history syncer dhe arrita një performancë të pranueshme.
Fakti është që ky është kufiri i performancës ku duhet bërë diçka.
TimescaleDB. 80,000 nvps
Detyra ime kryesore është të provoj mundësitë e TimescaleDB nga ngarkesa e Zabbix. 80 mijë vlera në sekondë është shumë, frekuenca e mbledhjes së metricave (përveç Yandex-it, natyrisht) dhe një 'setup' mjaft i madh.
Në çdo grafik ka një rënie - kjo është pikërisht migrimi i të dhënave. Pas rënieve në serverin Zabbix, profili i ngarkesës së history syncer u ndryshua ndjeshëm - ra tri herë.
TimescaleDB lejon që të dhënat të futen praktikisht tri herë më shpejt dhe të përdorë më pak HistoryCache.
Për pasojë, ju do të merrni të dhëna në kohë.
TimescaleDB. 120,000 nvps
Më pas e rita numrin e elementeve të dhënash deri në 500 mijë. Detyra kryesore ishte të provoj mundësitë e TimescaleDB - kam marrë një vlerësim prej 125 mijë vlerash në sekondë.
Ky është një 'setup' funksional, që mund të punojë për një kohë të gjatë. Por pasi disku im ishte vetëm 1.5 TB, e mbushëm brenda disa ditëve.
Më e rëndësishmja, në të njëjtën kohë po krijoheshin parti të reja në TimescaleDB.
Për performancën, kjo është krejtësisht e paqartë. Kur krijohen parti në MySQL, për shembull, gjithçka është ndryshe. Zakonisht ndodh gjatë natës, sepse bllokon insert-in e përgjithshëm, punën me tabelat dhe mund të shkaktojë degradimin e shërbimit. Në rastin e TimescaleDB, kjo nuk ndodh.
Për shembull, do të tregoj një grafik nga shumë në community. Në figurë është aktivizuar TimescaleDB, për këtë arsye ngarkesa në përdorimin e io.weight në procesor ka rënë. Përdorimi i elementeve të proceseve të brendshme gjithashtu ka rënë. Dhe kjo është një makinë virtuale normale me disqe të zakonshme, jo SSD.
PĂ«rfundimet
TimescaleDB është një zgjidhje e mirë për 'setup' të vogla, që përballen me performancën e diskut. Ajo do të lejojë që të vazhdojë të punojë deri në migrimin e DB-së në një harduer më të shpejtë.
TimescaleDB është e thjeshtë për t'u konfiguruar, jep një rritje të performancës, punon mirë me Zabbix dhe ka avantazhe krahasuar me PostgreSQL..
Nëse përdorni PostgreSQL dhe nuk planifikoni ta ndryshoni, atëherë rekomandoj të përdorni PostgreSQL me zgjerimin TimescaleDB në lidhje me Zabbix.Ky zgjidhje funksionon efikas në 'setup' mesatar.
Kur themi 'performancĂ« e lartĂ«' - nĂ«nkuptojmĂ« . Pr ĐŸĐ¶ĐžĐŽĐ° Ń ĐČŃ ĐżĐŸĐ·ĐœĐ°Đ”ŃĐ” teknologjive dhe praktikat qĂ« lejojnĂ« shĂ«rbimeve t'i shĂ«rbejnĂ« miliona pĂ«rdoruesve, shumĂ« shpejt. Lista pĂ«r 7 dhe 8 nĂ«ntor e kemi pĂ«rgatitur, por mund tĂ« propozohet akoma.
Abonohuni në dhe , ku zbulojmë tiparet e konferencës së ardhshme dhe mësoni si të nxirrni maksimumin e përfitimit.
Burimi: habr.com
