{"id":38927,"date":"2019-10-31T22:26:48","date_gmt":"2019-10-31T19:26:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\/"},"modified":"2019-10-31T22:26:48","modified_gmt":"2019-10-31T19:26:48","slug":"vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","title":{"rendered":"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Zabbix \u00ebsht\u00eb nj\u00eb sistem monitorimi. Si \u00e7do sistem tjet\u00ebr, ai p\u00ebrballet me tre probleme kryesore t\u00eb \u00e7do sistemi monitorimi: mbledhjen dhe p\u00ebrpunimin e t\u00eb dh\u00ebnave, ruajtjen e historis\u00eb dhe pastrimin e saj.<\/p>\n<p>Etapet e marrjes, p\u00ebrpunimit dhe regjistrimit t\u00eb t\u00eb dh\u00ebnave marrin koh\u00eb. Pak, por p\u00ebr nj\u00eb sistem t\u00eb madh, kjo mund t\u00eb rezultoj\u00eb n\u00eb vonesa t\u00eb m\u00ebdha. Problemi i ruajtjes \u00ebsht\u00eb nj\u00eb \u00e7\u00ebshtje e qasjes n\u00eb t\u00eb dh\u00ebna. Ato p\u00ebrdoren p\u00ebr raportet, verifikimet dhe trigger-at. Vonesat n\u00eb qasjen n\u00eb t\u00eb dh\u00ebna gjithashtu ndikojn\u00eb n\u00eb performanc\u00eb. Kur DB-t\u00eb rriten, t\u00eb dh\u00ebnat joaktuale duhet t\u00eb fshihen. Fshirja \u00ebsht\u00eb nj\u00eb operacion i r\u00ebnd\u00eb, i cili gjithashtu konsumon nj\u00eb pjes\u00eb t\u00eb burimeve.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/9b7aa23705cd32b4d8d858ad78b181fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nProblemet e vonesave gjat\u00eb mbledhjes dhe ruajtjes n\u00eb Zabbix zgjidhen me ndihm\u00ebn e caching: disa lloje cache, caching n\u00eb DB. P\u00ebr t\u00eb zgjidhur problemin e tret\u00eb, caching nuk \u00ebsht\u00eb i p\u00ebrshtatsh\u00ebm, prandaj n\u00eb Zabbix \u00ebsht\u00eb p\u00ebrdorur TimescaleDB. P\u00ebr k\u00ebt\u00eb do t\u00eb flas\u00eb <strong>Andrei Gushchin<\/strong> \u2014 inxhinier i mb\u00ebshtetjes teknike <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/zabbix\/\">Zabbix SIA<\/a><\/noindex>. Andrei ka m\u00eb shum\u00eb se 6 vite n\u00eb mb\u00ebshtetje t\u00eb Zabbix dhe p\u00ebrball\u00ebt drejtp\u00ebrdrejt me performanc\u00ebn.<\/p>\n<p>Si funksionon TimescaleDB, \u00e7far\u00eb performanc\u00eb mund t\u00eb jap\u00eb krahasuar me PostgreSQL-n\u00eb e zakonshme? Cila \u00ebsht\u00eb roli i Zabbix p\u00ebr DB-n\u00eb e TimescaleDB? Si t\u00eb fillosh nga fillimi dhe si t\u00eb migrosh nga PostgreSQL dhe cilat jan\u00eb konfigurimet m\u00eb t\u00eb mira p\u00ebr performanc\u00eb? P\u00ebr gjith\u00eb k\u00ebt\u00eb m\u00eb posht\u00eb.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><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<h2>Sfidat e Performanc\u00ebs<\/h2>\n<p>\n\u00c7do sistem monitorimi p\u00ebrballet me sfida t\u00eb caktuara t\u00eb performanc\u00ebs. Un\u00eb do t\u00eb flas p\u00ebr tre prej tyre: mbledhja dhe p\u00ebrpunimi i t\u00eb dh\u00ebnave, ruajtja, pastrimi i historis\u00eb.<\/p>\n<p><strong>Mbledhja dhe p\u00ebrpunimi i t\u00eb dh\u00ebnave t\u00eb shpejta. <\/strong>Nj\u00eb sistem i mir\u00eb monitorimi duhet t\u00eb marr\u00eb t\u00eb dh\u00ebnat e gjitha dhe t'i p\u00ebrpunoj\u00eb ato sipas shprehjeve trigger \u2014 sipas kritereve t\u00eb tij. Pas p\u00ebrpunimit, sistemi duhet gjithashtu ta ruaj\u00eb shpejt k\u00ebto t\u00eb dh\u00ebna n\u00eb DB, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb p\u00ebrdoren m\u00eb von\u00eb.<\/p>\n<p><strong>Ruajtja e historis\u00eb. <\/strong>Nj\u00eb sistem i mir\u00eb monitorimi duhet t\u00eb ruaj\u00eb historin\u00eb n\u00eb DB dhe t\u00eb ofroj\u00eb qasje t\u00eb leht\u00eb n\u00eb metrika. Historia \u00ebsht\u00eb e nevojshme p\u00ebr ta p\u00ebrdorur at\u00eb n\u00eb raporte, grafik\u00eb, trigger-a, vlera prag dhe element\u00eb t\u00eb dh\u00ebnash t\u00eb llogaritur p\u00ebr njoftime.<\/p>\n<p><strong>Pastrimi i historis\u00eb. <\/strong>Ndonj\u00ebher\u00eb vjen nj\u00eb dit\u00eb kur nuk keni nevoj\u00eb t\u00eb mbani metrikat. Pse ju nevojiten t\u00eb dh\u00ebna t\u00eb mbledhura 5 vite m\u00eb par\u00eb, nj\u00eb muaj apo dy: disa nyje jan\u00eb fshir\u00eb, disa hoste apo metrika tashm\u00eb s\u2019kan\u00eb nevoj\u00eb, sepse jan\u00eb vjetruar dhe kan\u00eb pushuar s\u00eb u mbledhur. Nj\u00eb sistem monitorimi i mir\u00eb duhet t\u00eb ruaj\u00eb t\u00eb dh\u00ebna historike dhe koh\u00eb pas kohe t'i fshij\u00eb ato, p\u00ebr t\u00eb mos e mbingarkuar baz\u00ebn e t\u00eb dh\u00ebnave.<\/p>\n<blockquote><p>Pastrimi i t\u00eb dh\u00ebnave t\u00eb vjetruara \u00ebsht\u00eb nj\u00eb \u00e7\u00ebshtje e ndjeshme, q\u00eb ndikon shum\u00eb n\u00eb performanc\u00ebn e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave.<\/p><\/blockquote>\n<p><\/p>\n<h2>Keshimi n\u00eb Zabbix<\/h2>\n<p>\nN\u00eb Zabbix, thirrjet e para dhe t\u00eb dyta zgjidhen me an\u00eb t\u00eb keshimit. P\u00ebr mbledhjen dhe p\u00ebrpunimin e t\u00eb dh\u00ebnave p\u00ebrdoret memoria operative. P\u00ebr ruajtje \u2014 historit\u00eb n\u00eb triggera, grafika dhe elemente t\u00eb dh\u00ebnash t\u00eb llogaritura. N\u00eb an\u00ebn e Baz\u00ebs s\u00eb t\u00eb Dh\u00ebnave ka nj\u00eb keshim t\u00eb caktuar p\u00ebr zgjedhjet kryesore, p\u00ebr shembull, grafikat.<\/p>\n<p>Keshimi n\u00eb an\u00ebn e vet\u00eb serverit Zabbix \u00ebsht\u00eb:<\/p>\n<ul>\n<li>ConfigurationCache;<\/li>\n<li>ValueCache;<\/li>\n<li>HistoryCache;<\/li>\n<li>TrendsCache.<\/li>\n<\/ul>\n<p>\nLe t\u00eb flasim p\u00ebr to n\u00eb detaje.<\/p>\n<h3>ConfigurationCache<\/h3>\n<p>\nKy \u00ebsht\u00eb keshimi kryesor, ku ruhen metrikat, hostet, elementet e t\u00eb dh\u00ebnave, triggerat \u2014 gjith\u00e7ka q\u00eb nevojitet p\u00ebr Parap\u00ebrpunimin dhe mbledhjen e t\u00eb dh\u00ebnave.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/122708198f6cd136fbd0420876c06e9c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nT\u00eb gjitha k\u00ebto ruhen n\u00eb ConfigurationCache, p\u00ebr t\u00eb mos krijuar k\u00ebrkesa t\u00eb panevojshme n\u00eb Baz\u00ebn e t\u00eb Dh\u00ebnave. Pas nisjes s\u00eb serverit, ne p\u00ebrdit\u00ebsojm\u00eb k\u00ebt\u00eb kesh, krijojm\u00eb dhe p\u00ebrdit\u00ebsojm\u00eb periodikisht konfigurimet.<\/p>\n<h3>Grumbullimi i t\u00eb dh\u00ebnave<\/h3>\n<p>\nSchema \u00ebsht\u00eb mjaft e madhe, por e r\u00ebnd\u00ebsishme \u00ebsht\u00eb <strong>mbledh\u00ebsit<\/strong>. K\u00ebta jan\u00eb procese t\u00eb ndryshme mbledhjeje. Ata jan\u00eb p\u00ebrgjegj\u00ebs p\u00ebr lloje t\u00eb ndryshme mbledhjeje: mbledhin t\u00eb dh\u00ebna n\u00ebp\u00ebrmjet SNMP, IPMI dhe i d\u00ebrgojn\u00eb ato n\u00eb Parap\u00ebrpunim.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/deff5d9ff358f1b04b505d18c7770f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><em>Mbledh\u00ebsit jan\u00eb t\u00eb p\u00ebrshkuar me nj\u00eb vij\u00eb portokalli.<\/em><\/p>\n<p>N\u00eb Zabbix ka elemente t\u00eb dh\u00ebnash t\u00eb llogaritura agregat, q\u00eb nevojiten p\u00ebr t\u00eb agreguar kontrollet. N\u00ebse i kemi, i marrim t\u00eb dh\u00ebnat p\u00ebr to drejtp\u00ebrdrejt nga ValueCache.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nT\u00eb gjith\u00eb mbledh\u00ebsit p\u00ebrdorin ConfigurationCache p\u00ebr t\u00eb marr\u00eb detyra. M\u00eb pas, ata i d\u00ebrgojn\u00eb ato n\u00eb Parap\u00ebrpunim.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/116e25100ebdf9ed209a9b04fa6fa156.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nParap\u00ebrpunimi p\u00ebrdor ConfigurationCache p\u00ebr t\u00eb marr\u00eb hapat e Parap\u00ebrpunimit. Ai i p\u00ebrpunon k\u00ebto t\u00eb dh\u00ebna n\u00eb m\u00ebnyra t\u00eb ndryshme.<\/p>\n<p>Pas p\u00ebrpunimit t\u00eb t\u00eb dh\u00ebnave me ndihm\u00ebn e Parap\u00ebrpunimit, i ruajm\u00eb ato n\u00eb HistoryCache p\u00ebr t\u2019i p\u00ebrpunuar. K\u00ebtu p\u00ebrfundon mbledhja e t\u00eb dh\u00ebnave dhe kalojm\u00eb n\u00eb procesin kryesor n\u00eb Zabbix \u2014 <strong>history syncer<\/strong>, pasi kjo \u00ebsht\u00eb nj\u00eb arkitektur\u00eb monolite.<\/p>\n<p><em>Sh\u00ebnim: Parap\u00ebrpunimi \u00ebsht\u00eb nj\u00eb operacion mjaft i r\u00ebnd\u00eb. Me versionin 4.2 \u00ebsht\u00eb nxjerr\u00eb n\u00eb proxy. N\u00ebse keni nj\u00eb Zabbix shum\u00eb t\u00eb madh me shum\u00eb elemente t\u00eb dh\u00ebnash dhe frekuenc\u00eb mbledhjeje, kjo shum\u00eb leht\u00ebson pun\u00ebn.<\/em><\/p>\n<h3>ValueCache, cache p\u00ebr histori &amp; tendenca<\/h3>\n<p><\/p>\n<blockquote><p>History syncer \u00ebsht\u00eb procesi kryesor q\u00eb p\u00ebrpunon \u00e7do element t\u00eb dh\u00ebnash n\u00eb m\u00ebnyr\u00eb atomike, dometh\u00ebn\u00eb \u00e7do vler\u00eb.<\/p><\/blockquote>\n<p>\nHistory syncer merr vlerat nga HistoryCache dhe kontrollon n\u00eb Configuration n\u00ebse ka shkaktar\u00eb p\u00ebr llogaritjet. N\u00ebse ka, ai i llogarit.<\/p>\n<p>History syncer krijon nj\u00eb ngjarje, nj\u00eb eskalim, p\u00ebr t\u00eb krijuar njoftime, n\u00ebse k\u00ebrkohet sipas konfigurimit, dhe e regjistron. N\u00ebse ka shkaktar\u00eb p\u00ebr p\u00ebrpunim t\u00eb m\u00ebtejsh\u00ebm, ajo vler\u00eb e ruan n\u00eb ValueCache, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb mos shkonte n\u00eb tabel\u00ebn e historis\u00eb. K\u00ebshtu ValueCache mbushet me t\u00eb dh\u00ebna t\u00eb nevojshme p\u00ebr llogaritjen e shkaktar\u00ebve dhe elementeve t\u00eb llogaritura.<\/p>\n<p>History syncer regjistron t\u00eb gjitha t\u00eb dh\u00ebnat n\u00eb DB, dhe ajo \u2014 n\u00eb disk. Procesi i p\u00ebrpunimit p\u00ebrfundon k\u00ebtu.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4d74195381fda7756b0250982f6896be.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Keshimi n\u00eb DB<\/h3>\n<p>\nN\u00eb an\u00ebn e DB-s\u00eb ka cache t\u00eb ndryshme kur d\u00ebshiron t\u00eb shikosh grafikat ose raportet mbi ngjarjet:<\/p>\n<ul>\n<li><code>Innodb_buffer_pool<\/code> n\u00eb an\u00ebn e MySQL;<\/li>\n<li><code>shared_buffers<\/code> n\u00eb an\u00ebn e PostgreSQL;<\/li>\n<li><code>effective_cache_size<\/code> n\u00eb an\u00ebn e Oracle;<\/li>\n<li><code>shared_pool<\/code> n\u00eb an\u00ebn e DB2.<\/li>\n<\/ul>\n<p>\nKa shum\u00eb caches t\u00eb tjera, por k\u00ebto jan\u00eb kryesore p\u00ebr t\u00eb gjitha DB-t\u00eb. Ato lejojn\u00eb q\u00eb t\u00eb mbash t\u00eb dh\u00ebnat n\u00eb memorie q\u00eb shpesh nevojiten p\u00ebr k\u00ebrkesa. Ato kan\u00eb teknologji t\u00eb veta p\u00ebr k\u00ebt\u00eb.<\/p>\n<h3>Performanca e DB-s\u00eb \u00ebsht\u00eb kritike<\/h3>\n<p>\nZabbix serveri vazhdimisht mbledh t\u00eb dh\u00ebna dhe i regjistron ato. Kur rivendoset, ai gjithashtu lexon nga historia p\u00ebr t\u00eb mbushur ValueCache. Skriptet dhe raportet p\u00ebrdorin <strong>Zabbix API<\/strong>, i cili \u00ebsht\u00eb nd\u00ebrtuar mbi baz\u00ebn e nd\u00ebrfaqes Web. Zabbix API i qaset baz\u00ebs s\u00eb t\u00eb dh\u00ebnave dhe merr t\u00eb dh\u00ebnat e nevojshme p\u00ebr grafik\u00ebt, raportet, listat e ngjarjeve dhe problemet m\u00eb t\u00eb fundit.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/dd0efdc4e57c1197d448ce453012091e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nP\u00ebr vizualizimin \u2014 <strong>N\u00ebse tashm\u00eb e dini se \u00e7far\u00eb \u00ebsht\u00eb analiza e grupeve dhe se si ta b\u00ebni n\u00eb SQL, kaloni menj\u00ebher\u00eb n\u00eb seksionin e fundit.<\/strong>. Nd\u00ebr p\u00ebrdoruesit tan\u00eb, ky \u00ebsht\u00eb nj\u00eb zgjidhje popullore. Ai di t\u00eb d\u00ebrgoj\u00eb direkt k\u00ebrkesa p\u00ebrmes Zabbix API n\u00eb DB dhe krijon nj\u00eb konkurrenc\u00eb t\u00eb caktuar p\u00ebr marrjen e t\u00eb dh\u00ebnave. Prandaj nevojitet nj\u00eb konfigurim m\u00eb i holl\u00ebsish\u00ebm dhe m\u00eb i mir\u00eb i DB-s\u00eb p\u00ebr t'iu p\u00ebrgjigjur shpejt rezultat\u00ebve dhe testimeve.<\/p>\n<h2>Housekeeper<\/h2>\n<p>\nThirrja e tret\u00eb e performanc\u00ebs n\u00eb Zabbix \u00ebsht\u00eb pastrimi i historis\u00eb me an\u00eb t\u00eb Housekeeper. Ai respekton t\u00eb gjitha konfigurimet \u2014 n\u00eb element\u00ebt e t\u00eb dh\u00ebnave \u00ebsht\u00eb treguar se sa t\u00eb ruhet dinamika e ndryshimeve (trend\u00ebt) n\u00eb dit\u00eb.<\/p>\n<p>TrendsCache llogaritet n\u00eb fluks. Kur vijn\u00eb t\u00eb dh\u00ebnat, ne i agregojm\u00eb ato p\u00ebr nj\u00eb or\u00eb dhe i regjistrojm\u00eb n\u00eb tabelat p\u00ebr dinamiken e ndryshimeve t\u00eb trend\u00ebve.<\/p>\n<p>Housekeeper aktivizohet dhe fshin informacionin nga DB me \"selects\" t\u00eb zakonshme. Kjo nuk \u00ebsht\u00eb gjithmon\u00eb efektive, gj\u00eb q\u00eb mund t\u00eb kuptohet nga grafik\u00ebt e performanc\u00ebs s\u00eb proceseve t\u00eb brendshme.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/a3af1badd14b1092bc26e0b53845ae04.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGrafiku i kuq tregon se History syncer \u00ebsht\u00eb vazhdimisht i z\u00ebn\u00eb. Grafiku portokalli lart \u00ebsht\u00eb Housekeeper, i cili aktivizohet vazhdimisht. Ai pret q\u00eb DB t\u00eb fshij\u00eb t\u00eb gjitha rreshtat q\u00eb ai ka p\u00ebrcaktuar.<\/p>\n<p>Kur duhet t\u00eb \u00e7aktivizohet Housekeeper? P\u00ebr shembull, n\u00ebse ka nj\u00eb \u00abItem ID\u00bb dhe duhet t\u00eb fshihen 5 mij\u00eb rreshta n\u00eb nj\u00eb koh\u00eb t\u00eb caktuar. Natyrisht, kjo ndodh p\u00ebrmes indekseve. Por zakonisht dataset \u00ebsht\u00eb shum\u00eb i madh, dhe DB gjithsesi lexon nga disku dhe e ngre n\u00eb cache. Kjo gjithmon\u00eb \u00ebsht\u00eb nj\u00eb operacion shum\u00eb i shtrenjt\u00eb p\u00ebr DB dhe, n\u00eb var\u00ebsi t\u00eb madh\u00ebsive t\u00eb baz\u00ebs, mund t\u00eb shkaktoj\u00eb probleme n\u00eb performanc\u00eb.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/0778318b539fbe33318e8a7310f8a89b.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p>Housekeeper mund t\u00eb \u00e7aktivizohet leht\u00ebsisht. N\u00eb nd\u00ebrfaqen Web ka nj\u00eb cil\u00ebsim n\u00eb \u00abAdministration general\u00bb p\u00ebr Housekeeper. Ne e \u00e7aktivizojm\u00eb Housekeeping-un e brendsh\u00ebm p\u00ebr historin\u00eb e brendshme t\u00eb trendeve dhe ai nuk menaxhon m\u00eb k\u00ebt\u00eb.<\/p>\n<p>Housekeeper u \u00e7aktivizua, grafiket u rregulluan - \u00e7far\u00eb probleme t\u00eb mundshme mund t\u00eb ket\u00eb n\u00eb k\u00ebt\u00eb rast dhe \u00e7far\u00eb mund t\u00eb ndihmoj\u00eb n\u00eb zgjidhjen e thirrjes s\u00eb tret\u00eb p\u00ebr performanc\u00ebn?<\/p>\n<h2>Partitioning - seksionimi ose parcellimi<\/h2>\n<p>\nZakonisht, parcellimi konfigurimi b\u00ebhet n\u00eb m\u00ebnyra t\u00eb ndryshme n\u00eb \u00e7do DB relacional, q\u00eb kam p\u00ebrmendur. \u00c7do nj\u00eb ka teknologjin\u00eb e saj, por ato jan\u00eb t\u00eb ngjashme, n\u00eb p\u00ebrgjith\u00ebsi. Krijimi i nj\u00eb seksioni t\u00eb ri shpesh shkakton probleme t\u00eb caktuara.<\/p>\n<p>Zakonisht, seksionet konfigurohen n\u00eb var\u00ebsi t\u00eb \u00absetup-it\u00bb - numrit t\u00eb t\u00eb dh\u00ebnave q\u00eb gjenerohen n\u00eb nj\u00eb dit\u00eb. Zakonisht, Partitioning-u vendoset p\u00ebr nj\u00eb dit\u00eb, kjo \u00ebsht\u00eb minimumi. P\u00ebr trendet, seksione t\u00eb reja - p\u00ebr 1 muaj.<\/p>\n<p>Vlerat mund t\u00eb ndryshojn\u00eb n\u00eb rastin e nj\u00eb \u00absetup\u00bb shum\u00eb t\u00eb madh. N\u00ebse \u00absetup\u00bb i vog\u00ebl \u00ebsht\u00eb deri n\u00eb 5,000 nvps (vlera t\u00eb reja p\u00ebr sekond\u00eb), mesatarja - nga 5,000 deri n\u00eb 25,000, at\u00ebher\u00eb e madhe - mbi 25,000 nvps. K\u00ebto jan\u00eb instalime t\u00eb m\u00ebdha dhe shum\u00eb t\u00eb m\u00ebdha q\u00eb k\u00ebrkojn\u00eb konfigurim t\u00eb kujdessh\u00ebm t\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave.<\/p>\n<p>N\u00eb instalime shum\u00eb t\u00eb m\u00ebdha, nj\u00eb segment n\u00eb nj\u00eb dit\u00eb mund t\u00eb mos jet\u00eb optimal. Kam par\u00eb n\u00eb MySQL seksione mbi 40 GB dhe m\u00eb shum\u00eb p\u00ebr dit\u00eb. Ky \u00ebsht\u00eb nj\u00eb volum shum\u00eb i madh t\u00eb dh\u00ebnash, q\u00eb mund t\u00eb shkaktoj\u00eb probleme dhe duhet t\u00eb reduktohet.<\/p>\n<h3>\u00c7far\u00eb ofron Partitioning?<\/h3>\n<p>\n<strong>Seksionimi i tabelave<\/strong>. Zakonisht, k\u00ebto jan\u00eb skedar\u00eb t\u00eb ve\u00e7ant\u00eb n\u00eb disk. Plani i k\u00ebrkesave zgjidh m\u00eb optimal nj\u00eb seksion. Zakonisht, parcellimi p\u00ebrdoret sipas intervaleve - kjo \u00ebsht\u00eb e v\u00ebrtet\u00eb edhe p\u00ebr Zabbix. Ne p\u00ebrdorim atje \u00abtimestamp\u00bb - koha q\u00eb nga fillimi i epok\u00ebs. K\u00ebtu kemi numra t\u00eb zakonsh\u00ebm. Ju konfiguroni fillimin dhe fundin e dit\u00ebs - kjo \u00ebsht\u00eb nj\u00eb seksion.<\/p>\n<p><strong>Fshirje e shpejt\u00eb<\/strong> \u2014 <code>FSHI<\/code>Zgjedhet nj\u00eb skedar\/subtabela, e jo nj\u00eb grumbull rreshtash p\u00ebr t'u fshir\u00eb.<\/p>\n<p><strong>Duket se p\u00ebrshpejton marrjen e t\u00eb dh\u00ebnave.<\/strong> <code>SELECT<\/code> \u2014 p\u00ebrdor nj\u00eb ose m\u00eb shum\u00eb pjes\u00eb, dhe jo t\u00ebr\u00eb tabel\u00ebn. N\u00ebse i drejtoheni t\u00eb dh\u00ebnave t\u00eb dy dit\u00ebve m\u00eb par\u00eb, ato zgjidhen nga DB m\u00eb shpejt, sepse duhet t\u00eb ngarkohen n\u00eb cache dhe t\u00eb jepen vet\u00ebm nj\u00eb skedar, e jo nj\u00eb tabel\u00eb t\u00eb madhe.<\/p>\n<p>Shpesh shum\u00eb DB gjithashtu p\u00ebrmir\u00ebson. <code>SHTO<\/code> \u2014 inserimet n\u00eb tabel\u00ebn f\u00ebmij\u00eb.<\/p>\n<h2>TimescaleDB<\/h2>\n<p>\nP\u00ebr v 4.2 ne u fokusuam n\u00eb TimescaleDB. Ky \u00ebsht\u00eb nj\u00eb zgjerim p\u00ebr PostgreSQL me nj\u00eb nd\u00ebrfaqe natyrore. Zgjerimi punon efektivisht me t\u00eb dh\u00ebnat e serive kohore, pa humbur p\u00ebrfitimet e DB-ve rrelacionale. TimescaleDB gjithashtu partitizon automatikisht.<\/p>\n<p>N\u00eb TimescaleDB ekziston koncepti i <strong>hipertabel\u00ebs<\/strong> (hypertable), t\u00eb cil\u00ebn e krijoni. Ajo p\u00ebrmban <strong>skaje<\/strong> \u2014 pjesit\u00eb. Skajat jan\u00eb fragmente t\u00eb menaxhuara automatikisht t\u00eb hipertabel\u00ebs, t\u00eb cilat nuk ndikojn\u00eb n\u00eb fragmente t\u00eb tjera. P\u00ebr \u00e7do skaj ka nj\u00eb gam\u00eb t\u00eb ve\u00e7ant\u00eb kohore.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/91a24560ff12aa17f98689e3445f50e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB vs PostgreSQL<\/h3>\n<p>\nTimescaleDB funksionon v\u00ebrtet efektivisht. Prodhuesit e zgjerimit pretendojn\u00eb se ata p\u00ebrdorin nj\u00eb algorit\u00ebm m\u00eb t\u00eb sakt\u00eb p\u00ebr trajtimin e k\u00ebrkesave, ve\u00e7an\u00ebrisht t\u00eb <code>inserts<\/code>. Kur dimensionet e t\u00eb dh\u00ebnave q\u00eb futen rriten, algoritmi mb\u00ebshtet nj\u00eb performanc\u00eb t\u00eb vazhdueshme.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/52f042018180ffd2cb6a2cf4a3af603e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPas 200 milion rreshtash, PostgreSQL zakonisht fillon t\u00eb ngadal\u00ebsohet ndjesh\u00ebm dhe humbet performanc\u00ebn deri n\u00eb 0. TimescaleDB lejon efikasitetin n\u00eb inserimet \u2018inserts\u2019 me \u00e7do sasi t\u00eb dh\u00ebnash.<\/p>\n<h3>Instalimi<\/h3>\n<p>\nT\u00eb instalosh TimescaleDB \u00ebsht\u00eb mjaft e leht\u00eb p\u00ebr \u00e7do paket\u00eb. N\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.timescale.com\/v1.3\/getting-started\">dokumentacionin<\/a><\/noindex> \u00ebsht\u00eb p\u00ebrshkruar n\u00eb detaje \u2014 varet nga paketat zyrtare t\u00eb PostgreSQL. TimescaleDB mund t\u00eb nd\u00ebrtohet dhe kompilohet gjithashtu manualisht.<\/p>\n<p>P\u00ebr DB Zabbix thjesht aktivizojm\u00eb zgjerimin:<\/p>\n<pre><code class=\"sql\">echo \"CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;\" | sudo -u postgres psql zabbix<\/code><\/pre>\n<p>\nAktivizoni <code>zgjerimin<\/code> dhe krijoni at\u00eb p\u00ebr DB Zabbix. Hapi i fundit \u2014 krijimi i hipertabel\u00ebs.<\/p>\n<h3>Migrimi i tabelave t\u00eb historis\u00eb n\u00eb TimescaleDB<\/h3>\n<p>\nP\u00ebr k\u00ebt\u00eb ka nj\u00eb funksion t\u00eb ve\u00e7ant\u00eb <code>create_hypertable<\/code>:<\/p>\n<pre><code class=\"sql\">SELECT create_hypertable(\u2018history\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018history_unit\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018history_log\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018history_text\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018history_str\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018trends\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018trends_unit\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nUPDATE config SET db_extension=\u2019timescaledb\u2019, hk_history_global=1, hk_trends_global=1<\/code><\/pre>\n<p>\nFunksioni ka tre parametra. I pari \u2014<strong> tabela n\u00eb DB<\/strong>, p\u00ebr t\u00eb cil\u00ebn duhet t\u00eb krijohet hipertabela. T\u00eb dytin \u2014 <strong>fush\u00ebn<\/strong>, sipas t\u00eb cilit duhet t\u00eb krijohet <code>chunk_time_interval<\/code> \u2014 intervali i grumbujve t\u00eb particioneve q\u00eb duhet t\u00eb p\u00ebrdoren. N\u00eb rastin tim, intervalu \u00ebsht\u00eb nj\u00eb dit\u00eb \u2014 86 400.<\/p>\n<p>Parametri i tret\u00eb \u2014 <code><strong>migroj t\u00eb dh\u00ebnat<\/strong><\/code>. N\u00ebse vendoset <code>true<\/code>, t\u00eb gjitha t\u00eb dh\u00ebnat aktuale transferohen n\u00eb grumbujt e krijuar paraprakisht. Un\u00eb vet\u00eb kam p\u00ebrdorur <code>migroj t\u00eb dh\u00ebnat<\/code>. Kishte rreth 1 TB, q\u00eb zuri m\u00eb shum\u00eb se nj\u00eb or\u00eb. Edhe n\u00eb disa raste, gjat\u00eb testimeve, kam fshir\u00eb t\u00eb dh\u00ebnat historike simetrike q\u00eb nuk ishin t\u00eb nevojshme p\u00ebr ruajtje, p\u00ebr t'i shmangur ato.<\/p>\n<p>Hapi i fundit \u2014\u00a0<code><strong>UPDATE<\/strong><\/code>: n\u00eb <code>db_extension<\/code> vendosim <code>timescaledb<\/code>, p\u00ebr t'i treguar DB-s\u00eb se ka k\u00ebt\u00eb zgjerim. Zabbix e aktivizon at\u00eb dhe e p\u00ebrdor k\u00ebt\u00eb sintaks\u00eb e k\u00ebrkesa p\u00ebr DB-n\u00eb \u2014 ato ve\u00e7ori q\u00eb jan\u00eb t\u00eb nevojshme p\u00ebr TimescaleDB.<\/p>\n<h2>Konfigurimi i harduerit<\/h2>\n<p>\nKam p\u00ebrdorur dy server\u00eb. I pari \u2014 <strong>VMware-makina<\/strong>. Ajo \u00ebsht\u00eb mjaft e vog\u00ebl: 20 procesor\u00eb Intel\u00ae Xeon\u00ae CPU E5-2630 v 4 @ 2.20GHz, 16 GB memorie RAM dhe nj\u00eb disk SSD prej 200 GB.<\/p>\n<p>Kam instaluar aty PostgreSQL 10.8 me OS Debian 10.8-1.pgdg90+1 dhe sistemin e skedar\u00ebve xfs. T\u00eb gjitha jan\u00eb minimalisht konfigurur p\u00ebr t\u00eb p\u00ebrdorur sakt\u00ebsisht k\u00ebt\u00eb baz\u00eb t\u00eb dh\u00ebnash, p\u00ebrve\u00e7 asaj q\u00eb do t\u00eb p\u00ebrdor\u00eb vet\u00eb Zabbix.<\/p>\n<p>N\u00eb k\u00ebt\u00eb makin\u00eb ishte serveri Zabbix, PostgreSQL dhe <strong>agjent\u00ebt e ngarkes\u00ebs<\/strong>. Kam pasur 50 agjent\u00eb aktiv\u00eb, t\u00eb cilat p\u00ebrdornin <code>LoadableModule<\/code>, p\u00ebr t\u00eb gjeneruar shum\u00eb shpejt rezultatet e ndryshme: numra, stringa. E mbusha baz\u00ebn me shum\u00eb t\u00eb dh\u00ebna.<\/p>\n<p>Fillimisht, konfigurimi p\u00ebrmbante <strong>5 000 elemente<\/strong> t\u00eb dh\u00ebnash p\u00ebr \u00e7do host. Gati \u00e7do element p\u00ebrmbante nj\u00eb trigger, q\u00eb t\u00eb ishte e ngjashme me instalimet reale. N\u00eb disa raste kishte m\u00eb shum\u00eb se nj\u00eb trigger. N\u00eb nj\u00eb nyje t\u00eb rrjetit kishim <strong>3 000-7 000 triggera.<\/strong>.<\/p>\n<p>Intervali i azhurnimit t\u00eb elementeve t\u00eb dh\u00ebnash \u2014 <strong>4-7 sekonda<\/strong>Un\u00eb rregulloja ngarkes\u00ebn duke p\u00ebrdorur jo vet\u00ebm 50 agjent\u00eb, por shtoja edhe m\u00eb shum\u00eb. Po ashtu, me an\u00eb t\u00eb elementeve t\u00eb dh\u00ebnash, rregulloja dinamikisht ngarkes\u00ebn dhe ulja e intervalit t\u00eb rifreskimit n\u00eb 4 sekonda.<\/p>\n<h3>PostgreSQL. 35,000 nvps<\/h3>\n<p>\nS\u00eb pari, ndihesha n\u00eb k\u00ebt\u00eb harduer me PostgreSQL t\u00eb past\u00ebr \u2014 35,000 vlera n\u00eb sekond\u00eb. Si\u00e7 duket, futja e t\u00eb dh\u00ebnave merr fraksione sekonde \u2014 gjith\u00e7ka \u00ebsht\u00eb mir\u00eb dhe e shpejt\u00eb. E vetmja gj\u00eb \u00ebsht\u00eb se disku SSD prej 200 GB mbushet shpejt.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e84b2eb0f6fbbd902c5feab367c750ee.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKy \u00ebsht\u00eb dashboard-i standard i performanc\u00ebs Zabbix \u2014 t\u00eb serverit.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/c3afe021acf8e272813b8d8c2f82e762.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGrafiku i par\u00eb blu \u2014 numri i vlerave n\u00eb sekond\u00eb. Grafiku i dyt\u00eb n\u00eb t\u00eb djatht\u00eb \u2014 ngarkesa e proceseve t\u00eb nd\u00ebrtimit. Tret\u00ebsori \u2014 ngarkesa e proceseve t\u00eb brendshme t\u00eb nd\u00ebrtimit: history syncers dhe Housekeeper, i cili k\u00ebtu u krye p\u00ebr nj\u00eb koh\u00eb t\u00eb konsiderueshme.<\/p>\n<p>Grafiku i kat\u00ebrt tregon p\u00ebrdorimin e HistoryCache. Ky \u00ebsht\u00eb nj\u00eb tampon para futjes n\u00eb DB. Grafiku i gjelb\u00ebr i pest\u00eb tregon p\u00ebrdorimin e ValueCache, q\u00eb do t\u00eb thot\u00eb sa goditje ka pasur ValueCache p\u00ebr treguesit \u2014 kjo \u00ebsht\u00eb disa mij\u00ebra vlera n\u00eb sekond\u00eb.<\/p>\n<h3>PostgreSQL. 50,000 nvps<\/h3>\n<p>\nN\u00eb vazhdim, un\u00eb e rritja ngarkes\u00ebn n\u00eb 50,000 vlera n\u00eb sekond\u00eb n\u00eb k\u00ebt\u00eb harduer t\u00eb nj\u00ebjt\u00eb.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/8f10944486d5502b57d36059382d551b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGjat\u00eb ngarkes\u00ebs me Housekeeper, futja e 10,000 vlerave u regjistrua p\u00ebr 2-3 sekonda.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/5228c1735f0ee2da7f827093f3c7b1f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Housekeeper tashm\u00eb fillon t\u00eb pengoj\u00eb pun\u00ebn.<\/em><\/p>\n<p>Nga grafiku i tret\u00eb duket se, n\u00eb k\u00ebt\u00eb moment, ngarkesa e trapper-ve dhe history syncers \u00ebsht\u00eb ende n\u00eb nivelin 60%. N\u00eb grafikun e kat\u00ebrt, HistoryCache gjat\u00eb pun\u00ebs s\u00eb Housekeeper tashm\u00eb fillon t\u00eb mbushet mjaft aktivisht. Ai \u00ebsht\u00eb mbushur n\u00eb 20% \u2014 rreth 0.5 GB.<\/p>\n<h3>PostgreSQL. 80,000 nvps<\/h3>\n<p>\nM\u00eb pas, un\u00eb e rritja ngarkes\u00ebn n\u00eb 80,000 vlera n\u00eb sekond\u00eb. Kjo \u00ebsht\u00eb rreth 400,000 elemente t\u00eb dh\u00ebnash dhe 280,000 tregues.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/f6c6b0d6793f96523f7406e68f98c608.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Futja me ngarkes\u00ebn e tridhjet\u00eb history syncers \u00ebsht\u00eb tashm\u00eb mjaft e lart\u00eb.<\/em><\/p>\n<p>Po ashtu, un\u00eb e rritesha disa parametra: history syncers, memorie cache.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/6ca7edd76aea6fdec00a61a0a6dc34e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00eb harduerin tim, ngarkesa e history syncers u rrit n\u00eb maksimum. HistoryCache shpejt u mbush me t\u00eb dh\u00ebna \u2014 n\u00eb tampon u grumbulluan t\u00eb dh\u00ebna p\u00ebr trajtim.<\/p>\n<p>T\u00eb gjith\u00eb k\u00ebt\u00eb koh\u00eb kam monitoruar se si p\u00ebrdoret procesori, memoria RAM dhe parametrat e tjer\u00eb t\u00eb sistemit, dhe zbulova se shfryt\u00ebzimi i disqeve ishte maksimal.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e964a000156b561accd23b4e1644f4a8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nArrita t\u00eb p\u00ebrdor <strong>mund\u00ebsit\u00eb maksimale t\u00eb diskut<\/strong> n\u00eb k\u00ebt\u00eb harduer dhe n\u00eb k\u00ebt\u00eb makin\u00eb virtuale. Me nj\u00eb intensitet t\u00eb till\u00eb, PostgreSQL filloi t\u00eb hidhte t\u00eb dh\u00ebna mjaft aktivisht dhe disku tashm\u00eb nuk arrinte t\u00eb punonte n\u00eb regjistrimin dhe leximin.<\/p>\n<h3>Serveri i dyt\u00eb<\/h3>\n<p>\nKam mora nj\u00eb server tjet\u00ebr q\u00eb kishte tashm\u00eb 48 procesor\u00eb dhe 128 GB memorie RAM. E optimizova - instalova 60 history syncer dhe arrita nj\u00eb performanc\u00eb t\u00eb pranueshme.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/591fc759b336d5fb2091460036b136bf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFakti \u00ebsht\u00eb q\u00eb ky \u00ebsht\u00eb kufiri i performanc\u00ebs ku duhet b\u00ebr\u00eb di\u00e7ka.<\/p>\n<h3>TimescaleDB. 80,000 nvps<\/h3>\n<p>\nDetyra ime kryesore \u00ebsht\u00eb t\u00eb provoj mund\u00ebsit\u00eb e TimescaleDB nga ngarkesa e Zabbix. 80 mij\u00eb vlera n\u00eb sekond\u00eb \u00ebsht\u00eb shum\u00eb, frekuenca e mbledhjes s\u00eb metricave (p\u00ebrve\u00e7 Yandex-it, natyrisht) dhe nj\u00eb 'setup' mjaft i madh.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/aa569847e7bc31baab91661db1ee78a2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00eb \u00e7do grafik ka nj\u00eb r\u00ebnie - kjo \u00ebsht\u00eb pik\u00ebrisht migrimi i t\u00eb dh\u00ebnave. Pas r\u00ebnieve n\u00eb serverin Zabbix, profili i ngarkes\u00ebs s\u00eb history syncer u ndryshua ndjesh\u00ebm - ra tri her\u00eb.<\/p>\n<blockquote><p>TimescaleDB lejon q\u00eb t\u00eb dh\u00ebnat t\u00eb futen praktikisht tri her\u00eb m\u00eb shpejt dhe t\u00eb p\u00ebrdor\u00eb m\u00eb pak HistoryCache.<\/p><\/blockquote>\n<p>\nP\u00ebr pasoj\u00eb, ju do t\u00eb merrni t\u00eb dh\u00ebna n\u00eb koh\u00eb.<\/p>\n<h3>TimescaleDB. 120,000 nvps<\/h3>\n<p>\nM\u00eb pas e rita numrin e elementeve t\u00eb dh\u00ebnash deri n\u00eb 500 mij\u00eb. Detyra kryesore ishte t\u00eb provoj mund\u00ebsit\u00eb e TimescaleDB - kam marr\u00eb nj\u00eb vler\u00ebsim prej 125 mij\u00eb vlerash n\u00eb sekond\u00eb.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4770ca4030e1c086f2fd9305a12496bb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKy \u00ebsht\u00eb nj\u00eb 'setup' funksional, q\u00eb mund t\u00eb punoj\u00eb p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb. Por pasi disku im ishte vet\u00ebm 1.5 TB, e mbush\u00ebm brenda disa dit\u00ebve.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/1ad521b909a22a7db81a9ed802d348e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nM\u00eb e r\u00ebnd\u00ebsishmja, n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb po krijoheshin parti t\u00eb reja n\u00eb TimescaleDB.<\/p>\n<p>P\u00ebr performanc\u00ebn, kjo \u00ebsht\u00eb krejt\u00ebsisht e paqart\u00eb. Kur krijohen parti n\u00eb MySQL, p\u00ebr shembull, gjith\u00e7ka \u00ebsht\u00eb ndryshe. Zakonisht ndodh gjat\u00eb nat\u00ebs, sepse bllokon insert-in e p\u00ebrgjithsh\u00ebm, pun\u00ebn me tabelat dhe mund t\u00eb shkaktoj\u00eb degradimin e sh\u00ebrbimit. N\u00eb rastin e TimescaleDB, kjo nuk ndodh.<\/p>\n<p>P\u00ebr shembull, do t\u00eb tregoj nj\u00eb grafik nga shum\u00eb n\u00eb community. N\u00eb figur\u00eb \u00ebsht\u00eb aktivizuar TimescaleDB, p\u00ebr k\u00ebt\u00eb arsye ngarkesa n\u00eb p\u00ebrdorimin e io.weight n\u00eb procesor ka r\u00ebn\u00eb. P\u00ebrdorimi i elementeve t\u00eb proceseve t\u00eb brendshme gjithashtu ka r\u00ebn\u00eb. Dhe kjo \u00ebsht\u00eb nj\u00eb makin\u00eb virtuale normale me disqe t\u00eb zakonshme, jo SSD.<\/p>\n<p><img decoding=\"async\" alt=\"Performanc\u00eb e lart\u00eb dhe ndarje natyrale: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/bea0cd0f1448e1d1b3a5f979d51ce61c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>P\u00ebrfundimet<\/h2>\n<p>\n<strong>TimescaleDB \u00ebsht\u00eb nj\u00eb zgjidhje e mir\u00eb p\u00ebr 'setup' t\u00eb vogla<\/strong>, q\u00eb p\u00ebrballen me performanc\u00ebn e diskut. Ajo do t\u00eb lejoj\u00eb q\u00eb t\u00eb vazhdoj\u00eb t\u00eb punoj\u00eb deri n\u00eb migrimin e DB-s\u00eb n\u00eb nj\u00eb harduer m\u00eb t\u00eb shpejt\u00eb.<\/p>\n<p>TimescaleDB \u00ebsht\u00eb e thjesht\u00eb p\u00ebr t'u konfiguruar, jep nj\u00eb rritje t\u00eb performanc\u00ebs, punon mir\u00eb me Zabbix dhe <strong>ka avantazhe krahasuar me PostgreSQL.<\/strong>.<\/p>\n<p>N\u00ebse p\u00ebrdorni PostgreSQL dhe nuk planifikoni ta ndryshoni, at\u00ebher\u00eb rekomandoj <strong>t\u00eb p\u00ebrdorni PostgreSQL me zgjerimin TimescaleDB n\u00eb lidhje me Zabbix.<\/strong>Ky zgjidhje funksionon efikas n\u00eb 'setup' mesatar.<\/p>\n<blockquote>\n<p>Kur themi 'performanc\u00eb e lart\u00eb' - n\u00ebnkuptojm\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\">HighLoad++<\/a><\/noindex>. Pr \u043e\u0436\u0438\u0434\u0430 \u0448 \u0432\u044b \u043f\u043e\u0437\u043d\u0430\u0435\u0442\u0435 teknologjive dhe praktikat q\u00eb lejojn\u00eb sh\u00ebrbimeve t'i sh\u00ebrbejn\u00eb miliona p\u00ebrdoruesve, shum\u00eb shpejt. Lista <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/abstracts\">e raporteve<\/a><\/noindex> p\u00ebr 7 dhe 8 n\u00ebntor e kemi p\u00ebrgatitur, por <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/meetups\">mitapet<\/a><\/noindex> mund t\u00eb propozohet akoma.<\/p>\n<p>Abonohuni n\u00eb <noindex><a rel=\"nofollow\" href=\"http:\/\/eepurl.com\/VYVaf\">newsletter-in ton\u00eb<\/a><\/noindex> dhe <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/HighLoadChannel\">telegram<\/a><\/noindex>, ku zbulojm\u00eb tiparet e konferenc\u00ebs s\u00eb ardhshme dhe m\u00ebsoni si t\u00eb nxirrni maksimumin e p\u00ebrfitimit.<\/p>\n<\/blockquote>\n<p>Burimi: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/470902\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041a\u0430\u043a \u0438 \u043b\u044e\u0431\u0430\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u043e\u043d\u0430 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0441 \u0442\u0440\u0435\u043c\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u0432\u0441\u0435\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430: \u0441\u0431\u043e\u0440 \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0434\u0430\u043d\u043d\u044b\u0445, \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0441\u0442\u043e\u0440\u0438\u0438, \u0435\u0435 \u043e\u0447\u0438\u0441\u0442\u043a\u0430. \u042d\u0442\u0430\u043f\u044b \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f, \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 \u0432\u0440\u0435\u043c\u044f. \u041d\u0435\u043c\u043d\u043e\u0433\u043e, \u043d\u043e \u0434\u043b\u044f \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043b\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0438. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u0434\u0430\u043d\u043d\u044b\u043c. \u041e\u043d\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29204,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38927","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430.\" \/>\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\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.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\udd47\u0412\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: Zabbix \u0441 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 TimescaleDB | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\" \/>\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=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:26:48+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\udd47Performanc\u00eb e lart\u00eb dhe ndarje me origjin\u00eb: Zabbix me mb\u00ebshtetje p\u00ebr TimescaleDB | ProHoster","description":"Zabbix \u2014 \u00ebsht\u00eb nj\u00eb sistem monitorimi.","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","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\udd47\u0412\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: Zabbix \u0441 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 TimescaleDB | ProHoster","og:description":"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430.","og:url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","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":"2019-10-31T19:26:48+00:00","article:modified_time":"2019-10-31T19:26:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38927","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":"2026-01-23 23:59:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 21:14:06","updated":"2026-01-23 23:59:19","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\/38927","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=38927"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/38927\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/29204"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=38927"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=38927"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=38927"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}