{"id":55734,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","title":{"rendered":"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ne do ta shikojm\u00eb funksionimin e Zabbix me baz\u00ebn e t\u00eb dh\u00ebnave TimescaleDB si backend. Do t\u00eb tregojm\u00eb se si t\u00eb startoni nga e para dhe si t\u00eb migroni nga PostgreSQL. Gjithashtu, do t\u00eb japim teste krahasuese t\u00eb performanc\u00ebs s\u00eb dy konfiguracioneve.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/fb4f7ea4585b6dcdafec9d0d1e3a71e4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHighLoad++ Siberia 2019. Salla \"Tomsk\". 24 qershor, 16:00. Tezat dhe <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5390\">prezantimi<\/a><\/noindex>. Konferenca e ardhshme HighLoad++ do t\u00eb zhvillohet m\u00eb 6 dhe 7 prill 2020 n\u00eb Sh\u00ebn Petersburg. Detajet dhe biletat <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2sSxgBx\">n\u00eb lidhje<\/a><\/noindex>.<\/p>\n<p><b>Andrej Gushin (m\u00eb pas \u2013 A.G.):<\/b> \u2013 Un\u00eb jam inxhinier n\u00eb mb\u00ebshtetje teknike t\u00eb ZABBIX (m\u00eb pas \u2013 \"Zabbix\"), trajner. Kam mbi 6 vjet p\u00ebrvoj\u00eb n\u00eb mb\u00ebshtetje teknike dhe kam p\u00ebrballur drejtp\u00ebrdrejt me performanc\u00ebn. Sot do t\u00eb flas p\u00ebr performanc\u00ebn q\u00eb mund t\u00eb ofroj\u00eb TimescaleDB, n\u00eb krahasim me PostgreSQL 10. Gjithashtu, do t\u00eb jap disa informata hyr\u00ebse \u2013 p\u00ebr m\u00ebnyr\u00ebn se si funksionon.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Sfidat kryesore t\u00eb performanc\u00ebs: nga grumbullimi n\u00eb pastrimin e t\u00eb dh\u00ebnave<\/h3>\n<p>\nLe t\u00eb fillojm\u00eb me sfidat e caktuara t\u00eb performanc\u00ebs, me t\u00eb cilat p\u00ebrballen \u00e7do sistem monitorimi. Sfid\u00eb e par\u00eb e performanc\u00ebs \u00ebsht\u00eb mbledhja dhe p\u00ebrpunimi i shpejt\u00eb i t\u00eb dh\u00ebnave.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/a2cb78b549a55c3b59d7fcdb8b8865b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNj\u00eb sistem monitorimi i mir\u00eb duhet t\u00eb marr\u00eb dhe p\u00ebrpunoj\u00eb t\u00eb gjitha t\u00eb dh\u00ebnat me shpejt\u00ebsi dhe n\u00eb koh\u00eb, duke i p\u00ebrpunuar ato sipas shprehjeve provokuese, dometh\u00ebn\u00eb, duke i p\u00ebrpunuar sipas disa kritereve (n\u00eb sisteme t\u00eb ndryshme kjo \u00ebsht\u00eb ndryshe) dhe t\u00eb ruaj\u00eb n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave, n\u00eb m\u00ebnyr\u00eb q\u00eb k\u00ebto t\u00eb dh\u00ebna t\u00eb p\u00ebrdoren m\u00eb von\u00eb.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/a3ce55c3aec3eb93948150684838a5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSfid\u00eb e dyt\u00eb e performanc\u00ebs \u00ebsht\u00eb ruajtja e historis\u00eb. T\u00eb ruhen n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave shpesh dhe t\u00eb ken\u00eb qasje t\u00eb shpejt\u00eb dhe t\u00eb leht\u00eb n\u00eb k\u00ebto metrika q\u00eb jan\u00eb mbledhur p\u00ebr nj\u00eb periudh\u00eb t\u00eb caktuar kohe. E r\u00ebnd\u00ebsishme \u00ebsht\u00eb q\u00eb k\u00ebto t\u00eb dh\u00ebna t\u00eb jen\u00eb t\u00eb lehta p\u00ebr t'u marr\u00eb, t'i p\u00ebrdorni ato n\u00eb raporte, grafik\u00eb, n\u00eb shprehje provokuese, n\u00eb disa vlera pragore, p\u00ebr njoftime etj.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/325363d79f0270d620f956eeb8ab3402.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSfid\u00eb e tret\u00eb e performanc\u00ebs \u00ebsht\u00eb pastrimi i historis\u00eb, dometh\u00ebn\u00eb kur arrin nj\u00eb dit\u00eb kur nuk \u00ebsht\u00eb e nevojshme t\u00eb ruash disa metrika t\u00eb detajuara q\u00eb jan\u00eb mbledhur p\u00ebr 5 vjet (sikur edhe p\u00ebr muaj ose dy muaj). Disa nyje t\u00eb rrjetit jan\u00eb fshir\u00eb, ose disa hosta, metrikat nuk jan\u00eb m\u00eb t\u00eb nevojshme sepse jan\u00eb b\u00ebr\u00eb t\u00eb vjetra dhe kan\u00eb ndaluar s\u00eb mbledhuri. K\u00ebto duhet t\u00eb pastrohen, n\u00eb m\u00ebnyr\u00eb q\u00eb baza e t\u00eb dh\u00ebnave t\u00eb mos shnd\u00ebrrohet n\u00eb nj\u00eb madh\u00ebsi t\u00eb madhe. N\u00eb t\u00eb v\u00ebrtet\u00eb, pastrimi i historis\u00eb shpesh \u00ebsht\u00eb nj\u00eb provim serioz p\u00ebr magazinimin \u2013 zakonisht ndikon shum\u00eb te performanca.<\/p>\n<h3>Si t\u00eb zgjidhni problemet e caching-ut?<\/h3>\n<p>\nTani do t\u00eb flas\u00eb konkretisht p\u00ebr \u00abZabbix\u00bb. N\u00eb \u00abZabbix\u00bb, thirrjet e para dhe t\u00eb dyta zgjidhen p\u00ebrmes memorie t\u00eb arkivimit.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/d5510b31553ee8e63a0c240789d51622.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGrumbullimi dhe p\u00ebrpunimi i t\u00eb dh\u00ebnave \u2013 ne p\u00ebrdorim memorien operative p\u00ebr t\u00eb ruajtur t\u00eb gjitha k\u00ebto t\u00eb dh\u00ebna. Tani do t\u00eb flas\u00eb m\u00eb n\u00eb detaje rreth k\u00ebtyre t\u00eb dh\u00ebnave.<\/p>\n<p>Po ashtu, n\u00eb an\u00ebn e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave ka nj\u00eb arkivim t\u00eb caktuar p\u00ebr zgjedhjet kryesore \u2013 p\u00ebr grafiket, gj\u00ebrat e tjera.<\/p>\n<p>Arkivimi n\u00eb an\u00ebn e vet\u00eb serverit Zabbix: ne kemi ConfigurationCache, ValueCache, HistoryCache, TrendsCache. \u00c7far\u00eb jan\u00eb k\u00ebto?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/241a131145eccd280a7411c43b2cdce4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConfigurationCache \u2013 \u00ebsht\u00eb arkivi kryesor ku ruajm\u00eb metrikat, hostet, elementet e t\u00eb dh\u00ebnave, trigjerat; gjith\u00e7ka q\u00eb nevojitet p\u00ebr p\u00ebrpunimin paraprak, grumbullimin e t\u00eb dh\u00ebnave, se nga cilat hoste t\u00eb grumbullojm\u00eb dhe me \u00e7far\u00eb frekuencash. T\u00eb gjitha k\u00ebto ruhen n\u00eb ConfigurationCache, q\u00eb t\u00eb mos shkojm\u00eb n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave, t\u00eb mos krijojm\u00eb k\u00ebrkesa t\u00eb panevojshme. Pas fillimit t\u00eb serverit, ne p\u00ebrdit\u00ebsojm\u00eb k\u00ebt\u00eb arkiv (e krijojm\u00eb) dhe e p\u00ebrdit\u00ebsojm\u00eb periodikisht (n\u00eb var\u00ebsi t\u00eb konfigurimit).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/474ac0db2e46aa945a0da62197f72987.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Arkivimi n\u00eb Zabbix. Grumbullimi i t\u00eb dh\u00ebnave<\/h3>\n<p>\nK\u00ebtu schema \u00ebsht\u00eb mjaft e madhe:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/a6ad9dbd5deebac5440433a47c693fcf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKryesor\u00ebt n\u00eb schema \u2013 jan\u00eb k\u00ebta grumbullues:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/feb932586302e2284bd44595caf9ee1b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nK\u00ebta jan\u00eb proceset e grumbullimit, \u2018poller\u2019-at e ndrysh\u00ebm, q\u00eb jan\u00eb p\u00ebrgjegj\u00ebs p\u00ebr lloje t\u00eb ndryshme grumbullimesh. Ata grumbullojn\u00eb t\u00eb dh\u00ebna p\u00ebr icmp, ipmi, p\u00ebr protokolle t\u00eb ndryshme dhe e kalojn\u00eb t\u00eb gjitha k\u00ebto p\u00ebr p\u00ebrpunim paraprak.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nPo ashtu, n\u00ebse kemi elemente t\u00eb dh\u00ebnash t\u00eb llogaritura (ata q\u00eb jan\u00eb njohur me \u00abZabbix\u00bb e din\u00eb), ka elemente t\u00eb dh\u00ebnash t\u00eb llogaritura, agregative \u2013 ne i marrim ato direkt nga ValueCache. Si mbushet ai, do e tregoj m\u00eb von\u00eb. T\u00eb gjith\u00eb k\u00ebta grumbullues p\u00ebrdorin ConfigurationCache p\u00ebr t\u00eb marr\u00eb detyrat e tyre dhe pastaj i kalojn\u00eb p\u00ebr p\u00ebrpunim paraprak.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/3948ee1167c52856949c25e2043be974.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nP\u00ebrpunimi paraprak po ashtu p\u00ebrdor ConfigurationCache p\u00ebr t\u00eb marr\u00eb hapat e p\u00ebrpunimit paraprak, e p\u00ebrpunon k\u00ebto t\u00eb dh\u00ebna n\u00eb m\u00ebnyra t\u00eb ndryshme. Duke filluar nga versioni 4.2, ai \u00ebsht\u00eb transferuar n\u00eb proxy. Kjo \u00ebsht\u00eb shum\u00eb e dobishme, sepse vet\u00eb p\u00ebrpunimi paraprak \u00ebsht\u00eb nj\u00eb operacion mjaft i r\u00ebnd\u00eb. Dhe n\u00ebse keni nj\u00eb \u2018Zabbix\u2019 shum\u00eb t\u00eb madh, me shum\u00eb elemente t\u00eb dh\u00ebnash dhe nj\u00eb frekuenc\u00eb t\u00eb lart\u00eb grumbullimi, at\u00ebher\u00eb kjo e leht\u00ebson ndjesh\u00ebm pun\u00ebn.<\/p>\n<p>Pas p\u00ebrpunimit t\u00eb k\u00ebtyre t\u00eb dh\u00ebnave n\u00eb ndonj\u00eb m\u00ebnyr\u00eb p\u00ebrmes p\u00ebrpunimit paraprak, i ruajm\u00eb ato n\u00eb HistoryCache p\u00ebr t'i p\u00ebrpunuar m\u00eb tej. K\u00ebtu p\u00ebrfundon grumbullimi i t\u00eb dh\u00ebnave. Ne kalojm\u00eb n\u00eb procesin kryesor.<\/p>\n<h3>Puna e History syncer<\/h3>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/66539e4184d041ed84f797080226ba24.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nProcesi kryesor n\u00eb \u00abZabbix\u00bb (q\u00eb \u00ebsht\u00eb nj\u00eb arkitektur\u00eb monolitike) \u00ebsht\u00eb History syncer. Ky \u00ebsht\u00eb procesi kryesor q\u00eb merret me p\u00ebrpunimin atomar t\u00eb \u00e7do elementi t\u00eb t\u00eb dh\u00ebnave, pra t\u00eb \u00e7do vler\u00ebsimi:<\/p>\n<ul>\n<li>vjen nj\u00eb vler\u00eb (e merr nga HistoryCache);<\/li>\n<li>kontrollon n\u00eb Configuration syncer: a ka ndonj\u00eb trigger p\u00ebr kalkulim \u2013 i llogarit ato;<br \/>\nn\u00ebse ka \u2013 krijon ngjarje, krijon eskalim p\u00ebr t\u00eb krijuar nj\u00eb njoftim, n\u00ebse \u00ebsht\u00eb e nevojshme sipas konfigurimit;<\/li>\n<li>regjistron trigger p\u00ebr p\u00ebrpunim t\u00eb m\u00ebtejsh\u00ebm, agregim; n\u00ebse e agregoni p\u00ebr or\u00ebn e fundit e k\u00ebshtu me radh\u00eb, kjo vler\u00eb ruhet n\u00eb ValueCache, p\u00ebr t\u00eb mos u kthyer n\u00eb tabel\u00ebn e historis\u00eb; k\u00ebshtu, ValueCache plot\u00ebsohet me t\u00eb dh\u00ebnat e nevojshme p\u00ebr t\u00eb llogaritur trigger, elemente t\u00eb llogaritura etj.;<\/li>\n<li>pastaj History syncer ruan t\u00eb gjitha t\u00eb dh\u00ebnat n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave;<\/li>\n<li>baza e t\u00eb dh\u00ebnave i shkruan ato n\u00eb disk \u2013 k\u00ebtu procesi i p\u00ebrpunimit p\u00ebrfundon.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Baza e t\u00eb dh\u00ebnave. Keshimi<\/h3>\n<p>\nN\u00eb an\u00ebn e DB, kur d\u00ebshironi t\u00eb shikoni grafik\u00ebt ose ndonj\u00eb raporte p\u00ebr ngjarjet, ka disa caches. Por n\u00eb kuad\u00ebr t\u00eb k\u00ebsaj prezentimi nuk do t\u00eb flas p\u00ebr to.<\/p>\n<p>P\u00ebr MySQL ka Innodb_buffer_pool, gjithashtu shum\u00eb caches t\u00eb ndryshme q\u00eb gjithashtu mund t\u00eb konfigurohen.<br \/>\nPor k\u00ebto jan\u00eb \u2013 kryesoret:<\/p>\n<ul>\n<li>shared_buffers;<\/li>\n<li>effective_cache_size;<\/li>\n<li>shared_pool.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/925e7abb21cfaa2516ff2b33ab161dc0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nP\u00ebr t\u00eb gjitha bazat e t\u00eb dh\u00ebnave e kam treguar se ka caching t\u00eb caktuar q\u00eb lejon mbajtjen n\u00eb memorie ato t\u00eb dh\u00ebna q\u00eb jan\u00eb shpesh t\u00eb nevojshme p\u00ebr k\u00ebrkesa. Aty kan\u00eb teknologjit\u00eb e tyre p\u00ebr k\u00ebt\u00eb.<\/p>\n<h3>P\u00ebr performanc\u00ebn e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave<\/h3>\n<p>\nP\u00ebrkat\u00ebsisht, ka nj\u00eb ambient konkurrues, pra serveri \u00abZabbix\u00bb mbledh t\u00eb dh\u00ebna dhe i shkruan ato. Kur rindez, ai gjithashtu lexon nga historia p\u00ebr t\u00eb mbushur ValueCache dhe k\u00ebshtu me radh\u00eb. K\u00ebtu mund t\u00eb keni skenar\u00eb dhe raporte q\u00eb p\u00ebrdorin \u00abZabbix\u00bb-API, i cili \u00ebsht\u00eb nd\u00ebrtuar n\u00eb baz\u00eb t\u00eb nd\u00ebrfaqes s\u00eb uebit. \u00abZabbix\u00bb-API hyn n\u00eb DB dhe merr t\u00eb dh\u00ebnat e nevojshme p\u00ebr t\u00eb marr\u00eb grafik\u00ebt, raportet ose nj\u00eb list\u00eb ngjarjesh, problemet m\u00eb t\u00eb fundit.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/10a55cb1af660aace3172a572bea6692.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNj\u00eb zgjidhje shum\u00eb e njohur p\u00ebr vizualizim \u00ebsht\u00eb Grafana, q\u00eb e p\u00ebrdorin p\u00ebrdoruesit tan\u00eb. Ajo mund t\u00eb hyj\u00eb drejtp\u00ebrdrejt si p\u00ebrmes \u00abZabbix\u00bb-API, ashtu edhe p\u00ebrmes DB. Ajo gjithashtu krijon nj\u00eb konkurrenc\u00eb t\u00eb caktuar p\u00ebr marrjen e t\u00eb dh\u00ebnave: nevojitet nj\u00eb konfigurim m\u00eb i holl\u00ebsish\u00ebm dhe i mir\u00eb i DB p\u00ebr t\u00eb p\u00ebrmbushur shp\u00ebrndarjen e shpejt\u00eb t\u00eb rezultateve dhe testimeve.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/8a008e55dbee5635d386cec2fc1c40f5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Pastrimi i Historis\u00eb. N\u00eb Zabbix ka Housekeeper<\/h3>\n<p>\nThirrja e tret\u00eb q\u00eb p\u00ebrdoret n\u00eb \u00abZabbix\u00bb \u00ebsht\u00eb pastrimi i historis\u00eb me ndihm\u00ebn e Housekeeper. \u00abHousekeeper\u00bb respekton t\u00eb gjitha cil\u00ebsimet, pra kemi n\u00eb element\u00ebt e t\u00eb dh\u00ebnave sa t\u00eb ruajm\u00eb (n\u00eb dit\u00eb), sa t\u00eb ruajm\u00eb trendet, dinamik\u00ebn e ndryshimeve.<\/p>\n<p>Nuk e tregova p\u00ebr TrendCache, t\u00eb cilin e llogarisim n\u00eb koh\u00eb reale: t\u00eb dh\u00ebnat arrijn\u00eb, ne i agregojm\u00eb p\u00ebr nj\u00eb or\u00eb (kryesisht kjo \u00ebsht\u00eb numri p\u00ebr or\u00ebn e fundit), numri mesatar \/ minimal dhe i regjistrojm\u00eb k\u00ebt\u00eb nj\u00eb her\u00eb n\u00eb or\u00eb n\u00eb tabel\u00ebn e dinamik\u00ebs s\u00eb ndryshimeve (\u00abTrendet\u00bb). \u00abHousekeeper\u00bb aktivizohet dhe fshin t\u00eb dh\u00ebnat nga DB me ndihm\u00ebn e selekton\u00ebve t\u00eb zakonsh\u00ebm, \u00e7ka nuk \u00ebsht\u00eb gjithmon\u00eb efikase.<\/p>\n<p>Si t\u00eb kuptoni se kjo nuk \u00ebsht\u00eb efikase? Mund t\u00eb shihni nj\u00eb pamje t\u00eb till\u00eb n\u00eb grafiket e performanc\u00ebs s\u00eb proceseve t\u00eb brendshme:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/f413ec989491d4186a05c779978e2f6d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHistoria juaj e sinkronizimit \u00ebsht\u00eb vazhdimisht e angazhuar (grafiku i kuq). Dhe grafiku \u00abportokalli\u00bb, q\u00eb shkon lart. Ky \u00ebsht\u00eb \u00abHousekeeper\u00bb, i cili aktivizohet dhe pret nga DB q\u00eb t\u00eb fshij\u00eb t\u00eb gjitha rreshtat q\u00eb ai ka caktuar.<\/p>\n<p>Merrni nj\u00eb ID t\u00eb ndonj\u00eb Artikulli: duhet t\u00eb fshini 5 mij\u00eb t\u00eb fundit; sigurisht, sipas indekseve. Por zakonisht dataset-i \u00ebsht\u00eb mjaft i madh \u2013 baza e t\u00eb dh\u00ebnave megjithat\u00eb e lexon k\u00ebt\u00eb nga disku dhe e ngre n\u00eb cache, dhe kjo \u00ebsht\u00eb nj\u00eb operacion shum\u00eb i shtrenjt\u00eb p\u00ebr DB. N\u00eb var\u00ebsi t\u00eb madh\u00ebsive t\u00eb saj, kjo mund t\u00eb sjell\u00eb disa probleme t\u00eb performanc\u00ebs.<\/p>\n<p>Mund ta \u00e7aktivizoni \u00abHousekeeper\u00bb n\u00eb nj\u00eb m\u00ebnyr\u00eb t\u00eb thjesht\u00eb \u2013 kemi nd\u00ebrfaqen e njohur t\u00eb uebit. Cil\u00ebsimi n\u00eb Administration general (cil\u00ebsimet p\u00ebr \u00abHousekeeper\u00bb) ne \u00e7aktivizojm\u00eb housekeeping-un e brendsh\u00ebm p\u00ebr historin\u00eb dhe trendet e brendshme. P\u00ebr rrjedhoj\u00eb, \u00abHousekeeper\u00bb nuk menaxhon m\u00eb k\u00ebt\u00eb:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/c9dc3ca86e7fd0c1229f6b9bc5d31270.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00c7far\u00eb mund t\u00eb b\u00ebni m\u00eb tej? E keni \u00e7aktivizuar, grafiket tuaj jan\u00eb rregulluar... \u00c7far\u00eb probleme mund t\u00eb dalin m\u00eb pas n\u00eb k\u00ebt\u00eb rast? \u00c7far\u00eb mund t\u00eb ndihmoj\u00eb?<\/p>\n<h3>Particionimi (sekcionimi)<\/h3>\n<p>\nZakonisht kjo inkorporohet n\u00eb \u00e7do baz\u00eb t\u00eb dh\u00ebnash relacionale, t\u00eb cilat i p\u00ebrmenda, n\u00eb m\u00ebnyra t\u00eb ndryshme. N\u00eb MySQL ka teknologjin\u00eb e saj. Por n\u00eb p\u00ebrgjith\u00ebsi ato jan\u00eb shum\u00eb t\u00eb ngjashme, n\u00ebse flasim p\u00ebr PostgreSQL 10 dhe MySQL. Sigurisht, ka shum\u00eb ndryshime t\u00eb brendshme, si \u00ebsht\u00eb realizuar gjith\u00e7ka dhe si ndikon gjith\u00e7ka n\u00eb performanc\u00eb. Por n\u00eb p\u00ebrgjith\u00ebsi, krijimi i nj\u00eb partie t\u00eb re shpesh t\u00eb \u00e7on gjithashtu n\u00eb disa probleme t\u00eb caktuara.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/729114d61794314e19383f09ee9b5d61.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00eb var\u00ebsi t\u00eb setup-it tuaj (sa shum\u00eb t\u00eb dh\u00ebna krijohen p\u00ebr nj\u00eb dit\u00eb), zakonisht vendoset minimumi \u2013 1 dit\u00eb\/pjes\u00eb, dhe p\u00ebr \"trendet\", dinamika e ndryshimeve \u2013 1 muaj\/pjes\u00eb e re. Kjo mund t\u00eb ndryshoj\u00eb, n\u00ebse keni nj\u00eb setup shum\u00eb t\u00eb madh.<\/p>\n<p>M\u00eb lejoni t'ju them p\u00ebrmasat e setup-it: deri n\u00eb 5 mij\u00eb vlera t\u00eb reja p\u00ebr sekond\u00eb (nvps e ashtuquajtura) \u2013 kjo do t\u00eb konsiderohet nj\u00eb \"setup\" i vog\u00ebl. I mes\u00ebm \u2013 nga 5 deri n\u00eb 25 mij\u00eb vlera n\u00eb sekond\u00eb. Gjith\u00e7ka q\u00eb kalon \u2013 \u00ebsht\u00eb nj\u00eb instalim i madh dhe shum\u00eb i madh, q\u00eb k\u00ebrkon nj\u00eb konfigurim shum\u00eb t\u00eb kujdessh\u00ebm t\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave.<\/p>\n<p>N\u00eb instalimet shum\u00eb t\u00eb m\u00ebdha, 1 dit\u00eb \u2013 mund t\u00eb mos jet\u00eb optimale. Un\u00eb kam par\u00eb personalisht n\u00eb MySQL pjes\u00eb deri n\u00eb 40 gigabajt p\u00ebr dit\u00eb (dhe mund t\u00eb jen\u00eb m\u00eb shum\u00eb). Ky \u00ebsht\u00eb nj\u00eb volum shum\u00eb i madh t\u00eb dh\u00ebnash, q\u00eb mund t\u00eb \u00e7oj\u00eb n\u00eb disa probleme. Duhet ta zvog\u00ebloni.<\/p>\n<h3>P\u00ebrse \u00ebsht\u00eb e nevojshme pjes\u00ebtimi?<\/h3>\n<p>\n\u00c7far\u00eb ofron Pjes\u00ebtimi, mendoj se t\u00eb gjith\u00eb e din\u00eb \u2013 kjo \u00ebsht\u00eb ndarja e tabelave. Shpesh, k\u00ebto jan\u00eb skedar\u00eb t\u00eb ve\u00e7ant\u00eb n\u00eb disk dhe k\u00ebrkesa t\u00eb shpejta. Ai p\u00ebrzgjedh m\u00eb optimalisht nj\u00eb pjes\u00eb, n\u00ebse \u00ebsht\u00eb pjes\u00eb e zakonshme e ndarjes.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/4920fb3415733799f0a90b1bc7af0114.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nP\u00ebr \"Zabbix\", n\u00eb ve\u00e7anti, p\u00ebrdoret sipas rangut, sipas intervalit, pra ne p\u00ebrdorim timestamp (numri normal, koha q\u00eb nga fillimi i epok\u00ebs). Ju caktoni fillimin e dit\u00ebs\/fundin e dit\u00ebs, dhe kjo \u00ebsht\u00eb nj\u00eb pjes\u00eb. P\u00ebr rrjedhoj\u00eb, n\u00ebse k\u00ebrkoni t\u00eb dh\u00ebna t\u00eb dy dit\u00ebve m\u00eb par\u00eb, gjith\u00e7ka merret nga baza e t\u00eb dh\u00ebnave m\u00eb shpejt, sepse duhet t\u00eb ngarkohet vet\u00ebm nj\u00eb skedar n\u00eb cache dhe t\u00eb jepet (dhe jo nj\u00eb tabel\u00eb e madhe).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/f5ee4e0b471eb5ebe701615aa617d66d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nShum\u00eb baze t\u00eb dh\u00ebnash gjithashtu p\u00ebrshpejtojn\u00eb insertin (shtimin n\u00eb nj\u00eb tabel\u00eb t\u00eb f\u00ebmij\u00ebs). Nd\u00ebrsa po flas n\u00eb m\u00ebnyr\u00eb abstrakte, por kjo \u00ebsht\u00eb gjithashtu e mundur. Pjes\u00ebtimi shpesh ndihmon.<\/p>\n<h3>Elasticsearch p\u00ebr NoSQL<\/h3>\n<p>\nS\u00eb fundmi, n\u00eb 3.4, ne implementuam nj\u00eb zgjidhje p\u00ebr NoSQL. Shtuam mund\u00ebsin\u00eb p\u00ebr t\u00eb shkruar n\u00eb Elasticsearch. Ju mund t\u00eb shkruani disa lloje t\u00eb ve\u00e7anta: zgjidhni \u2013 ose shkruani numra, ose disa simbole; ne kemi tekst t\u00eb vargut, mund t\u00eb shkruani logje n\u00eb Elasticsearch... P\u00ebr rrjedhoj\u00eb, nd\u00ebrfaqja e uebit do t\u00eb lidhet gjithashtu me Elasticsearch. Kjo funksionon shk\u00eblqyer n\u00eb disa raste, por n\u00eb momentin e tanish\u00ebm mund t\u00eb p\u00ebrdoret.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/24fe7d19c9e42474cd786ba59846c18c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB. Hyper-tabela<\/h3>\n<p>\nP\u00ebr 4.4.2 ne kemi v\u00ebn\u00eb re nj\u00eb gj\u00eb, si\u00e7 \u00ebsht\u00eb TimescaleDB. \u00c7far\u00eb \u00ebsht\u00eb kjo? Kjo \u00ebsht\u00eb nj\u00eb shtes\u00eb p\u00ebr PostgreSQL, q\u00eb do t\u00eb thot\u00eb se ka nj\u00eb nd\u00ebrfaqe native p\u00ebr PostgreSQL. P\u00ebrve\u00e7 k\u00ebsaj, kjo shtes\u00eb lejon q\u00eb t\u00eb punoni shum\u00eb m\u00eb efektivisht me t\u00eb dh\u00ebnat e caktuara me koh\u00eb dhe gjithashtu ka ndarje automatike. Si duket kjo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/de921f06453476215b6240ab9da6fae1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKjo \u00ebsht\u00eb hypertable \u2013 ka nj\u00eb koncept t\u00eb till\u00eb n\u00eb Timescale. Kjo \u00ebsht\u00eb nj\u00eb hipertabel\u00eb q\u00eb krijoni, dhe n\u00eb t\u00eb gjenden chunks. Chunks jan\u00eb ndarje, jan\u00eb tabelat f\u00ebmij\u00ebt, n\u00ebse nuk gaboj. Kjo \u00ebsht\u00eb me t\u00eb v\u00ebrtet\u00eb efektive.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/719eb3f5d8c9f57544dfc4010850610c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB dhe PostgreSQL<\/h3>\n<p>\nSipas prodhuesve t\u00eb TimescaleDB, ata p\u00ebrdorin nj\u00eb algorit\u00ebm m\u00eb t\u00eb sakt\u00eb p\u00ebr p\u00ebrpunimin e k\u00ebrkesave, sidomos p\u00ebr insertimet, i cili lejon t\u00eb ket\u00eb nj\u00eb performanc\u00eb af\u00ebrsisht t\u00eb vazhdueshme me rritjen e madh\u00ebsis\u00eb s\u00eb dataset-inserimit. Do t\u00eb thot\u00eb, pas 200 milion rreshtash, PostgreSQL fillon t\u00eb humbas\u00eb shum\u00eb n\u00eb performanc\u00eb, duke r\u00ebn\u00eb literally n\u00eb zero, nd\u00ebrsa 'Timescale' lejon q\u00eb t\u00eb inseroni sa m\u00eb efektivisht t\u00eb jet\u00eb e mundur me \u00e7do sasi t\u00eb t\u00eb dh\u00ebnash.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/a613d505a9dfe6008551ce981da7b24e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Si t\u00eb instaloni TimescaleDB? E gjith\u00eb kjo \u00ebsht\u00eb e thjesht\u00eb!<\/h3>\n<p>\nKa n\u00eb dokumentacionin e tij, p\u00ebrshkruar \u2013 mund t\u00eb instalohet nga paketat p\u00ebr \u00e7do... Ajo varet nga paketat zyrtare t\u00eb 'PostgreSQL'. Mund t\u00eb kompiloni manualisht. K\u00ebshtu ndodhi q\u00eb m\u00eb duhej t\u00eb kompiloj p\u00ebr DB.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/6767927fa92260103d318f9aa70ef5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00eb 'Zabbix' ne thjesht aktivizojm\u00eb Shtes\u00ebn. Mendoj se ata q\u00eb kan\u00eb p\u00ebrdorur Shtes\u00ebn n\u00eb 'PostgreSQL'... Thjesht e aktivizoni Shtes\u00ebn, e krijoni p\u00ebr DB 'Zabbix' q\u00eb p\u00ebrdorni.<\/p>\n<p>Dhe hapi i fundit...<\/p>\n<h3>TimescaleDB. Migrimi i tabelave t\u00eb historis\u00eb<\/h3>\n<p>\nJu nevojitet t\u00eb krijoni hypertable. P\u00ebr k\u00ebt\u00eb ka nj\u00eb funksion t\u00eb ve\u00e7ant\u00eb \u2013 Krijoni hypertable. N\u00eb t\u00eb, si parametrin e par\u00eb duhet t\u00eb tregoni tabel\u00ebn q\u00eb \u00ebsht\u00eb e nevojshme n\u00eb k\u00ebt\u00eb DB (p\u00ebr t\u00eb cil\u00ebn duhet t\u00eb krijoni hipertabel\u00ebn).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/47350f79fd9829c12685c1df8f0ff9a6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFusha mbi t\u00eb cil\u00ebn duhet t\u00eb krijoni, dhe chunk_time_interval (kjo \u00ebsht\u00eb intervali i chunks (ndarjeve, q\u00eb duhet t\u00eb p\u00ebrdoren). 86,400 \u2013 kjo \u00ebsht\u00eb nj\u00eb dit\u00eb. <\/p>\n<p>Parametri migrate_data: n\u00ebse e vendosni n\u00eb true, at\u00ebher\u00eb kjo transferon t\u00eb gjitha t\u00eb dh\u00ebnat aktuale n\u00eb chunks e krijuara m\u00eb par\u00eb.<\/p>\n<p>Un\u00eb vet\u00eb kam p\u00ebrdorur migrate_data \u2013 kjo merr nj\u00eb koh\u00eb t\u00eb konsiderueshme, n\u00eb var\u00ebsi t\u00eb madh\u00ebsis\u00eb s\u00eb DB tuaj. Kam pasur m\u00eb shum\u00eb se nj\u00eb terabajt \u2013 krijimi zgjati m\u00eb shum\u00eb se nj\u00eb or\u00eb. N\u00eb disa raste, gjat\u00eb testimit, kam fshir\u00eb t\u00eb dh\u00ebnat historike p\u00ebr tekstin (history_text) dhe stringun (history_str), q\u00eb t\u00eb mos i transferoja \u2013 ato n\u00eb t\u00eb v\u00ebrtet\u00eb nuk m\u00eb interesonin.<\/p>\n<p>Dhe p\u00ebrdit\u00ebsimi p\u00ebrfundimtar e b\u00ebjm\u00eb n\u00eb db_extention ton\u00eb: vendosim timescaledb, n\u00eb m\u00ebnyr\u00eb q\u00eb DB dhe, ve\u00e7an\u00ebrisht, \"Zabbix\" t\u00eb kuptoj se ekziston db_extention. Ai e aktivizon dhe p\u00ebrdor sintaks\u00ebn e duhur dhe k\u00ebrkesat ndaj DB, duke p\u00ebrdorur tashm\u00eb ato \"karakteristika\" q\u00eb jan\u00eb t\u00eb nevojshme p\u00ebr TimescaleDB.<\/p>\n<h3>Konfigurimi i serverit<\/h3>\n<p>\nKam p\u00ebrdorur dy server\u00eb. Serveri i par\u00eb \u00ebsht\u00eb nj\u00eb makin\u00eb virtuale mjaft e vog\u00ebl, 20 procesor\u00eb, 16 gigabajt ram. E konfigurova me \"Postgres\" 10.8:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/990805374a2380a5c645c578404489bd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSistemi operativ ishte Debian, sistemi i skedar\u00ebve \u2013 xfs. B\u00ebra konfigurime minimale, p\u00ebr t\u00eb p\u00ebrdorur pik\u00ebrisht k\u00ebt\u00eb baz\u00eb t\u00eb dh\u00ebnash, duke p\u00ebrjashtuar at\u00eb q\u00eb do t\u00eb p\u00ebrdorte vet\u00eb \"Zabbix\". N\u00eb k\u00ebt\u00eb makin\u00eb kishte \"Zabbix\"-server, PostgreSQL dhe agjent\u00eb ngarkese.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/a6efa9ab9cd58f0061d04f13fe31018c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKam p\u00ebrdorur 50 agjent\u00eb aktiv\u00eb, t\u00eb cil\u00ebt p\u00ebrdorin LoadableModule, p\u00ebr t\u00eb gjeneruar shpejt rezultate t\u00eb ndryshme. Atyre iu gjeneruan rreshta, numra dhe k\u00ebshtu me radh\u00eb. E mbushja DB me nj\u00eb sasi t\u00eb madhe t\u00eb dh\u00ebnash. Fillimisht, konfigurimi p\u00ebrmbante 5 mij\u00eb element\u00eb t\u00eb dh\u00ebnash p\u00ebr \u00e7do host, dhe rreth \u00e7do element t\u00eb dh\u00ebnash p\u00ebrmbante nj\u00eb trigger \u2013 n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb ishte nj\u00eb konfigurim real. Ndonj\u00ebher\u00eb, p\u00ebr p\u00ebrdorim k\u00ebrkohet edhe m\u00eb shum\u00eb se nj\u00eb trigger.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/d5a3c306402e08bf2532eb6203a4aab4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIntervali i p\u00ebrdit\u00ebsimit, ngarkesa e vet\u00eb e rregullova duke p\u00ebrdorur jo vet\u00ebm 50 agjent\u00eb (shtova edhe), por dhe me ndihm\u00ebn e elementeve dinamike t\u00eb dh\u00ebnash dhe e uli intervalin e p\u00ebrdit\u00ebsimit n\u00eb 4 sekonda.<\/p>\n<h3>Test i performanc\u00ebs. PostgreSQL: 36 mij\u00eb NVPs<\/h3>\n<p>\nAktivizimi i par\u00eb, konfigurimi i par\u00eb ishte n\u00eb PostgreSQL t\u00eb past\u00ebr 10 n\u00eb k\u00ebt\u00eb hardware (35 mij\u00eb vlera n\u00eb sekond\u00eb). N\u00eb p\u00ebrgjith\u00ebsi, si\u00e7 duket n\u00eb ekran, futja e t\u00eb dh\u00ebnave merr fraksione sekondash \u2013 gjith\u00e7ka \u00ebsht\u00eb mir\u00eb dhe e shpejt\u00eb, SSD-t\u00eb (200 gigabajt). E vetmja gj\u00eb \u00ebsht\u00eb se 20 GB mbushen mjaft shpejt.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/6803a64fedd26093b9117a036d2993ae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDo t\u00eb ket\u00eb shum\u00eb prej k\u00ebtyre grafik\u00ebve. Kjo \u00ebsht\u00eb nj\u00eb dashboard standard i performanc\u00ebs s\u00eb \"Zabbix\"-serverit.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/081cc11c6bf42db3f8f16b6cc4e6ee0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGrafiku i par\u00eb \u2013 numri i vlerave n\u00eb sekond\u00eb (blu, n\u00eb majtas lart), 35 mij\u00eb vlera n\u00eb k\u00ebt\u00eb rast. Kjo (n\u00eb qend\u00ebr lart) \u00ebsht\u00eb ngarkesa e proceseve t\u00eb mbledhjes, dhe kjo (n\u00eb majtas djathtas) \u00ebsht\u00eb ngarkesa e proceseve t\u00eb brendshme: history syncers dhe housekeeper, t\u00eb cil\u00ebt k\u00ebtu (n\u00eb qend\u00ebr posht\u00eb) u kryen p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb.<\/p>\n<p>Ky ky\u00e7 n\u00eb qend\u00ebr tregon p\u00ebrdorimin e ValueCache \u2013 sa goditje ValueCache p\u00ebr gjeneruesit (disa mij\u00ebra vlera n\u00eb sekond\u00eb). Nj\u00eb tjet\u00ebr grafik i r\u00ebnd\u00ebsish\u00ebm \u00ebsht\u00eb ai i kat\u00ebrt (n\u00eb fund t\u00eb majt\u00eb), i cili tregon p\u00ebrdorimin e HistoryCache, p\u00ebr t\u00eb cilin kam folur, q\u00eb \u00ebsht\u00eb nj\u00eb tampon para se t\u00eb futet n\u00eb DB.<\/p>\n<h3>Testi i performanc\u00ebs. PostgreSQL: 50 mij\u00eb NVPs<\/h3>\n<p>\nPastaj e rita ngarkes\u00ebn n\u00eb 50 mij\u00eb vlera n\u00eb sekond\u00eb n\u00eb k\u00ebt\u00eb hardware. Gjat\u00eb ngarkimit nga 'Housekeeper', 10 mij\u00eb vlera u regjistruan n\u00eb 2-3 sekonda me llogaritjen. Kjo, n\u00eb fakt, \u00ebsht\u00eb e dukshme n\u00eb ekranin pasues:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/80824da986dbee2f8d5ebe0ead4fbcfd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n'Housekeeper' tashm\u00eb fillon t\u00eb pengoj\u00eb funksionimin, por n\u00eb p\u00ebrgjith\u00ebsi ngarkesa e sinkronizuesve t\u00eb historis\u00eb \u00ebsht\u00eb ende n\u00eb nivelin 60 % (grafiku i tret\u00eb, n\u00eb t\u00eb djatht\u00eb lart). HistoryCache tashm\u00eb gjat\u00eb funksionimit t\u00eb 'Housekeeper' fillon t\u00eb mbushet aktivisht (n\u00eb fund t\u00eb majt\u00eb). Ai ishte rreth gjysm\u00eb gigabajt, mbushej me 20%.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/9e1bcd4f3b9f3e8a1c9a36b2083ec61b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Testi i performanc\u00ebs. PostgreSQL: 80 mij\u00eb NVPs<\/h3>\n<p>\nPastaj e rita n\u00eb 80 mij\u00eb vlera n\u00eb sekond\u00eb:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/13ae1589d6b9d35b4dda9c6c7d989cc2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIshte rreth 400 mij\u00eb elemente t\u00eb dh\u00ebnash, 280 mij\u00eb gjenerues. Regjistrimi, si\u00e7 e shihni, nga ngarkesa e sinkronizuesve t\u00eb historis\u00eb (t\u00eb cil\u00ebt ishin 30) ishte tashm\u00eb mjaft i lart\u00eb. Pastaj fillova t\u00eb rita parametrat e ndrysh\u00ebm: sinkronizuesit e historis\u00eb, cache\u2026 N\u00eb k\u00ebt\u00eb hardware, ngarkesa e sinkronizuesve t\u00eb historis\u00eb filloi t\u00eb rritej n\u00eb maksimum, praktikisht 'n\u00eb raft' \u2013 p\u00ebr rrjedhoj\u00eb, HistoryCache shkoi n\u00eb nj\u00eb ngarkes\u00eb shum\u00eb t\u00eb lart\u00eb:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/0ec528256c8fa7b16e1c7c95c8119535.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGjat\u00eb gjith\u00eb k\u00ebsaj kohe kam v\u00ebzhguar t\u00eb gjith\u00eb parametrat e sistemit (si p\u00ebrdoret procesori, memoria e rastit) dhe zbulova se shfryt\u00ebzimi i disqeve ishte maksimal \u2013 arrita mund\u00ebsin\u00eb maksimale t\u00eb k\u00ebtij disku n\u00eb k\u00ebt\u00eb hardware, n\u00eb k\u00ebt\u00eb makin\u00eb virtuale. 'Postgres' filloi t\u00eb heq\u00eb t\u00eb dh\u00ebnat mjaft aktivisht me k\u00ebt\u00eb intensitet, dhe disku nuk po arrinte m\u00eb t\u00eb regjistronte, lexonte\u2026<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/0809dbd7638e7ee003ea24c611984a0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMora nj\u00eb server tjet\u00ebr, i cili tashm\u00eb kishte 48 procesor\u00eb dhe 128 gigabajt memorie t\u00eb rastit:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/53410b502a4574aac5d40f1a2a6d3f42.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGjithashtu e 'modifikoja' \u2013 vendosa History syncer (60 cop\u00eb) dhe arrita nj\u00eb performanc\u00eb t\u00eb k\u00ebnaqshme. N\u00eb fakt, ne nuk jemi 'n\u00eb raft', por ndoshta kjo \u00ebsht\u00eb tashm\u00eb kufiri i performanc\u00ebs, ku \u00ebsht\u00eb e nevojshme t\u00eb merret di\u00e7ka n\u00eb konsiderat\u00eb.<\/p>\n<h3>Testi i performanc\u00ebs. TimescaleDB: 80 mij\u00eb NVPs<\/h3>\n<p>\nIshte q\u00ebllimi im kryesor \u2013 t\u00eb p\u00ebrdorja TimescaleDB. N\u00eb \u00e7do grafik \u00ebsht\u00eb e dukshme nj\u00eb r\u00ebnie:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/b0064068895a34b93b5aa6771aba05cb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nK\u00ebto d\u00ebshtime jan\u00eb pik\u00ebrisht migrimi i t\u00eb dh\u00ebnave. Pas k\u00ebsaj, n\u00eb serverin \"Zabbix\", profili i ngarkes\u00ebs s\u00eb historian\u00ebve \u00ebsht\u00eb ndryshuar ndjesh\u00ebm, si\u00e7 e shihni, ai lejon t\u00eb futen t\u00eb dh\u00ebnat gati 3 her\u00eb m\u00eb shpejt dhe p\u00ebrdor m\u00eb pak HistoryCache \u2013 p\u00ebrgjith\u00ebsisht, t\u00eb dh\u00ebnat do t\u00eb d\u00ebrgohen n\u00eb koh\u00eb. Edhe nj\u00eb her\u00eb, 80 mij\u00eb vlera n\u00eb sekond\u00eb \u2013 \u00ebsht\u00eb nj\u00eb rit\u00ebm mjaft i lart\u00eb (sigurisht, jo p\u00ebr \"Yandex\"). N\u00eb t\u00ebr\u00ebsi, \u00ebsht\u00eb nj\u00eb setup mjaft i madh, me nj\u00eb server.<\/p>\n<h3>Testi i performanc\u00ebs PostgreSQL: 120 mij\u00eb NVPs<\/h3>\n<p>\nM\u00eb pas e rita vler\u00ebn e numrit t\u00eb elementeve t\u00eb dh\u00ebnash deri n\u00eb gjysm\u00eb milioni dhe arrita nj\u00eb vler\u00eb t\u00eb kalkuluar prej 125 mij\u00eb n\u00eb sekond\u00eb:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/7d0cf2ef7c6691c1bbf4b90afd34e4bb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDhe mora k\u00ebto grafika:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/9c09333a50e016921a8a5b70e00397a1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPraktikisht, ky \u00ebsht\u00eb nj\u00eb setup funksional, ai mund t\u00eb punoj\u00eb p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb. Por pasi kisha nj\u00eb disk prej vet\u00ebm 1.5 terabajt\u00ebsh, e shpenzova at\u00eb p\u00ebr disa dit\u00eb. M\u00eb e r\u00ebnd\u00ebsishmja, n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb, u krijuan partit\u00eb e reja n\u00eb TimescaleDB, dhe kjo p\u00ebr performanc\u00ebn kaloi krejt\u00ebsisht pa u v\u00ebn\u00eb re, gj\u00eb q\u00eb nuk mund t\u00eb thuhet p\u00ebr MySQL.<\/p>\n<p>Zakonisht partit\u00eb krijohen nat\u00ebn, sepse kjo ndalon gjith\u00e7ka sa i p\u00ebrket futjes dhe pun\u00ebs me tabelat, dhe mund t\u00eb \u00e7oj\u00eb n\u00eb degradimin e sh\u00ebrbimit. N\u00eb k\u00ebt\u00eb rast, kjo nuk ndodhi! Detyra kryesore ishte t\u00eb provonim mund\u00ebsit\u00eb e TimescaleDB. U arrit nj\u00eb num\u00ebr i till\u00eb: 120 mij\u00eb vlera n\u00eb sekond\u00eb.<\/p>\n<p>Gjithashtu ka n\u00eb komunitet shembuj:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/66aa6b1d4c559d12082e4d91b6a1ca10.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNj\u00eb person gjithashtu aktivizoi TimescaleDB dhe ngarkesa n\u00eb p\u00ebrdorimin e io.weight ra n\u00eb procesor; dhe p\u00ebrdorimi i elementeve t\u00eb proceseve t\u00eb brendshme gjithashtu ra fal\u00eb aktivizimit t\u00eb TimescaleDB. Dhe blloqet jan\u00eb blloqe t\u00eb zakonshme, pra nj\u00eb virtualizues i zakonsh\u00ebm n\u00eb blloqet e zakonshme (jo SSD)!<\/p>\n<p>P\u00ebr ndonj\u00eb setup t\u00eb vog\u00ebl, q\u00eb hasin n\u00eb performanc\u00ebn e disku, TimescaleDB, si\u00e7 mendoj, \u00ebsht\u00eb nj\u00eb zgjidhje shum\u00eb e mir\u00eb. Ai do t\u00eb lejoj\u00eb t\u00eb vazhdoj pun\u00ebn deri sa t\u00eb migroj n\u00eb pajisje m\u00eb t\u00eb shpejta p\u00ebr databaz\u00ebn.<\/p>\n<p>Ftoj t\u00eb gjith\u00ebve n\u00eb ngjarjet tona: Konferenca - n\u00eb Mosk\u00eb, Samiti - n\u00eb Rig\u00eb. P\u00ebrdorni kanalet tona - \"Telegram\", forum, IRC. N\u00ebse keni ndonj\u00eb pyetje - vini t\u00eb flasim me ne n\u00eb stend\u00eb, mund t\u00eb diskutojm\u00eb p\u00ebr gjith\u00e7ka.<\/p>\n<h3>Pyetjet e publikut<\/h3>\n<p>\nPyetja e publikut (m\u00eb von\u00eb \u2013 P): \u2013 N\u00ebse TimescaleDB \u00ebsht\u00eb kaq e leht\u00eb p\u00ebr t'u konfiguruar dhe ofron nj\u00eb rritje t\u00eb till\u00eb t\u00eb performanc\u00ebs, ndoshta duhet ta p\u00ebrdorim si nj\u00eb praktik\u00eb t\u00eb mir\u00eb p\u00ebr konfigurimin e \u00abZabbix\u00bb me \u00abPostgreSQL\u00bb? A ka ndonj\u00eb penges\u00eb ose disavantazh n\u00eb k\u00ebt\u00eb zgjidhje, apo vall\u00eb, n\u00ebse vendosa t\u00eb p\u00ebrdor \u00abZabbix\u00bb, mund t\u00eb marr \u00abPostgreSQL\u00bb, ta instaloj \u00abTimescale\u00bb menj\u00ebher\u00eb dhe ta shfryt\u00ebzoj pa u shqet\u00ebsuar p\u00ebr ndonj\u00eb problem?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/314845a019724806283a957b15d857cc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>AG:<\/b> \u2013 Po, do t\u00eb thosha se kjo \u00ebsht\u00eb nj\u00eb rekomandim i mir\u00eb: t\u00eb p\u00ebrdorni \u00abPostgreSQL\u00bb menj\u00ebher\u00eb me zgjerimin TimescaleDB. Si\u00e7 kam th\u00ebn\u00eb, ka shum\u00eb komente t\u00eb mira, ndon\u00ebse kjo \u00abve\u00e7ori\u00bb \u00ebsht\u00eb eksperimentale. Por n\u00eb t\u00eb v\u00ebrtet\u00eb, testet tregojn\u00eb se kjo \u00ebsht\u00eb nj\u00eb zgjidhje e shk\u00eblqyer (me TimescaleDB), dhe mendoj se do t\u00eb zhvillohet! Ne po ndjekim se si po zhvillohet kjo zgjerim dhe do t\u00eb rregullojm\u00eb at\u00eb q\u00eb nevojitet.<\/p>\n<p>Gjat\u00eb zhvillimit ne u mb\u00ebshtet\u00ebm n\u00eb nj\u00eb nga \u00abve\u00e7orit\u00eb\u00bb e tyre t\u00eb njohura: atje mund t\u00eb punonit pak ndryshe me \u00e7unkat. Por pastaj ata e hoq\u00ebn at\u00eb n\u00eb versionin e ardhsh\u00ebm dhe na duhej t\u00eb mos mb\u00ebshteteshim n\u00eb at\u00eb kod. Do t\u00eb rekomandoja ta p\u00ebrdornit k\u00ebt\u00eb zgjidhje n\u00eb shum\u00eb sete. N\u00ebse po p\u00ebrdorni MySQL... P\u00ebr sete t\u00eb mesme \u00e7do zgjidhje funksionon mir\u00eb.<\/p>\n<p><b>P:<\/b> \u2013 N\u00eb graph\u00ebt e fundit nga komuniteti, kishte nj\u00eb grafik me \u00abHousekeeperin\u00bb:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/d01549b6b9b97d8bdf5372efe05d9039.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAi vazhdoi t\u00eb punonte. \u00c7far\u00eb b\u00ebn \u00abHousekeeperi\u00bb n\u00eb rastin e TimescaleDB?<\/p>\n<p><b>AG:<\/b> \u2013 Tani nuk mund t\u00eb them sakt\u00ebsisht \u2013 do ta shikoj kodin dhe do t\u00eb them m\u00eb n\u00eb detaje. Ai p\u00ebrdor k\u00ebrkesat e TimescaleDB jo p\u00ebr t\u00eb fshir\u00eb \u00e7unkat, por si\u00e7 duket agregon. Deri tani nuk jam i gatsh\u00ebm t\u00eb p\u00ebrgjigjem p\u00ebr k\u00ebt\u00eb pyetje teknike. N\u00eb stend\u00eb sot ose nes\u00ebr do t\u00eb sqarojm\u00eb.<\/p>\n<p><b>P:<\/b> \u2013 Kam nj\u00eb pyetje t\u00eb ngjashme \u2013 p\u00ebr performanc\u00ebn e operacionit t\u00eb fshirjes n\u00eb \u00abTimescale\u00bb.<br \/>\nP (p\u00ebrgjigja e publikut): \u2013 Kur fshini t\u00eb dh\u00ebna nga tabela, n\u00ebse e b\u00ebni k\u00ebt\u00eb p\u00ebrmes fshirjes, duhet t\u00eb kaloni p\u00ebrmes tabel\u00ebs \u2013 t\u00eb fshini, pastroni, t\u00eb sh\u00ebnoni gjith\u00e7ka p\u00ebr vakuumin e ardhsh\u00ebm. N\u00eb \u00abTimescale\u00bb, pasi keni \u00e7unka, mund t\u00eb hiqni. N\u00eb thelb, thjesht i thoni skedarit q\u00eb ndodhet n\u00eb big data: \u00abFshi!\u00bb<\/p>\n<p>\u00abTimeScale\u00bb simply understands that this chunk no longer exists. Since it integrates into the query planner, it captures your conditions in the select or other operations and immediately realizes that this chunk is gone \u2013 \u00abI will not go there anymore!\u00bb (data unavailable). That's it! This means that scanning the table is replaced by deleting the binary file, so it's fast.<\/p>\n<p><b>P:<\/b> \u2013 We've touched on the non-SQL topic already. As far as I understand, \u00abZabbix\u00bb doesn\u2019t really need to modify data, and all this is more like a log. Can we use specialized databases that can't change their data but can save, accumulate, and retrieve much faster \u2013 something like ClickHouse or something Kafka-like?.. Kafka is also a log! Can we somehow integrate them?<\/p>\n<p><b>AG:<\/b> \u2013 You can perform an export. We have a specific feature since version 3.4: you can write all historical files, events, and everything else to files; and then send them to any other database with some handler. In fact, many people redo and write directly to the database. Historical syncers write all this to files on the fly, rotate these files, etc., and you can transfer them into \u00abClickHouse\u00bb. I can't comment on future plans, but perhaps further support for NoSQL solutions (like \u00abClickHouse\u00bb) will continue.<\/p>\n<p><b>P:<\/b> \u2013 So, is it possible to completely eliminate Postgres?<\/p>\n<p><b>AG:<\/b> \u2013 Of course, the most challenging part in \u00abZabbix\u00bb is the historical tables, which create the most problems, along with the events. In this case, if you don\u2019t keep events for a long time and store history with trends in some other fast storage, then overall there shouldn\u2019t be any issues, I believe.<\/p>\n<p><b>P:<\/b> \u2013 Can you estimate how much faster everything will work if we switch to \u00abClickHouse\u00bb, for example?<\/p>\n<p><b>AG:<\/b> \u2013 I haven't tested it. I think, at the very least, similar numbers can be achieved quite easily, considering that \u00abClickHouse\u00bb has its own interface, but I can't say for sure. It's better to test. Everything depends on the configuration: how many hosts you have, and so on. Insertion is one thing, but you also need to retrieve this data \u2013 with Grafana or something else.<\/p>\n<p><b>P:<\/b> \u2013 So, it's about an equal competition, not a significant advantage for these fast databases?<\/p>\n<p><b>AG:<\/b> \u2013 I think when we integrate, we will have more accurate tests.<\/p>\n<p><b>P:<\/b> \u2013 Po shkuan ato RRD-t\u00eb e vjetra t\u00eb mira? \u00c7far\u00eb e detyroi kalimin n\u00eb bazat e t\u00eb dh\u00ebnave SQL? Fillimisht, t\u00eb gjitha metrikat mblidheshin n\u00eb RRD.<\/p>\n<p><b>AG:<\/b> \u2013 N\u00eb 'Zabbix', RRD mund t\u00eb ket\u00eb qen\u00eb n\u00eb nj\u00eb version shum\u00eb t\u00eb vjet\u00ebr. Gjithmon\u00eb kan\u00eb qen\u00eb bazat e t\u00eb dh\u00ebnave SQL \u2013 nj\u00eb qasje klasike. Qasja klasike \u00ebsht\u00eb MySQL, PostgreSQL (jan\u00eb ekzistuar shum\u00eb koh\u00eb m\u00eb par\u00eb). Ne ndoshta kurr\u00eb nuk e kemi p\u00ebrdorur nj\u00eb nd\u00ebrfaqe t\u00eb p\u00ebrbashk\u00ebt p\u00ebr bazat e t\u00eb dh\u00ebnave SQL dhe RRD.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje natyrale\" src=\"\/wp-content\/uploads\/2020\/01\/ac5f02494c63983601cc09c0b22e722b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"umRk94j5M8o\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/umRk94j5M8o\/hqdefault.jpg\" alt=\"Luaj videon\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h3>Pak reklam\u00eb \ud83d\ude42<\/h3>\n<p>\nFaleminderit q\u00eb po q\u00ebndroni me ne. Ju p\u00eblqen artikujt tan\u00eb? Doni t\u00eb shihni m\u00eb shum\u00eb materiale interesante? Na mb\u00ebshtesni duke b\u00ebr\u00eb nj\u00eb porosi ose duke rekomanduar tek miqt\u00eb tuaj, <noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/cloudvps\/nl\">VPS cloud p\u00ebr zhvillues nga $4.99<\/a><\/noindex>, <b>nj\u00eb analog unik i server\u00ebve entry-level q\u00eb e kemi shpikur p\u00ebr Ju:<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/347386\/\">E gjith\u00eb e v\u00ebrteta n\u00eb lidhje me VPS (KVM) E5-2697 v3 (6 B\u00ebrthama) 10GB DDR4 480GB SSD 1Gbps nga $19 ose si ta ndajm\u00eb sakt\u00ebsisht serverin?<\/a><\/noindex> (opcionet me RAID1 dhe RAID10, deri n\u00eb 24 b\u00ebrthama dhe deri n\u00eb 40GB DDR4 jan\u00eb t\u00eb disponueshme).<\/p>\n<p><b>Dell R730xd dyfish m\u00eb i lir\u00eb n\u00eb qend\u00ebr t\u00eb t\u00eb dh\u00ebnave Equinix Tier IV n\u00eb Amsterdam?<\/b> Vet\u00ebm te ne <b><noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/serversnl\">2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB nga $199<\/a><\/noindex> n\u00eb Holand\u00eb! <b>Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 nga $99!<\/b><\/b> Lexoni rreth <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">Si t\u00eb nd\u00ebrtoni nj\u00eb infrastruktur\u00eb t\u00eb klas\u00ebs korporative me p\u00ebrdorimin e server\u00ebve Dell R730xd E5-2650 v4 me \u00e7mim 9000 euro p\u00ebr pak para?<\/a><\/noindex><br \/>\n<br \/>Burimi: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ua-hosting\/blog\/485470\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL. \u0422\u0430\u043a\u0436\u0435 \u043f\u0440\u0438\u0432\u0435\u0434\u0435\u043c \u0441\u0440\u0430\u0432\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0435 \u0442\u0435\u0441\u0442\u044b \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0434\u0432\u0443\u0445 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0439. HighLoad++ Siberia 2019. \u0417\u0430\u043b \u00ab\u0422\u043e\u043c\u0441\u043a\u00bb. 24 \u0438\u044e\u043d\u044f, 16:00. \u0422\u0435\u0437\u0438\u0441\u044b \u0438 \u043f\u0440\u0435\u0437\u0435\u043d\u0442\u0430\u0446\u0438\u044f. \u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55734","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"sq_AL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-01-26T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:03:52+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47HighLoad++, Andri Gushin (Zabbix): performanc\u00eb e lart\u00eb dhe ndarje native | ProHoster","description":"Do t\u00eb shqyrtojm\u00eb funksionimin e Zabbix me baz\u00ebn e t\u00eb dh\u00ebnave TimescaleDB si backend. Do t\u00eb tregojm\u00eb si t\u00eb filloni nga zero dhe si t\u00eb migroni nga PostgreSQL.","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster","og:description":"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.","og:url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-26T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55734","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:37:39","updated":"2022-09-28 01:51:35","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/55734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=55734"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/55734\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=55734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=55734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=55734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}