{"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\/it\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","title":{"rendered":"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Esamineremo il funzionamento di Zabbix con il database TimescaleDB come backend. Mostreremo come avviare il servizio da zero e come migrare da PostgreSQL. Inoltre, presenteremo test comparativi delle prestazioni delle due configurazioni.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/fb4f7ea4585b6dcdafec9d0d1e3a71e4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHighLoad++ Siberia 2019. Sala \u00abTomsk\u00bb. 24 giugno, 16:00. Abstract e <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5390\">presentazione<\/a><\/noindex>. La prossima conferenza HighLoad++ si terr\u00e0 il 6 e 7 aprile 2020 a San Pietroburgo. Maggiori dettagli e biglietti <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2sSxgBx\">al link<\/a><\/noindex>.<\/p>\n<p><b>Andrey Gushchin (di seguito \u2013 AG):<\/b> \u2013 Sono ingegnere del supporto tecnico ZABBIX (di seguito \u2013 \u00abZabbix\u00bb), formatore. Lavoro nel supporto tecnico da oltre 6 anni e mi sono occupato direttamente delle performance. Oggi parler\u00f2 delle prestazioni che pu\u00f2 offrire TimescaleDB in confronto con il tradizionale PostgreSQL 10. Includer\u00f2 anche una parte introduttiva su come funziona tutto questo.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Le principali sfide delle prestazioni: dalla raccolta alla pulizia dei dati<\/h3>\n<p>\nCominciamo col dire che ci sono determinate sfide di performance con cui ogni sistema di monitoraggio deve confrontarsi. La prima di queste \u00e8 la raccolta e l'elaborazione rapida dei dati.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a2cb78b549a55c3b59d7fcdb8b8865b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn buon sistema di monitoraggio deve ricevere tempestivamente tutti i dati, elaborarli in base alle espressioni di trigger, ovvero secondo determinati criteri (che variano a seconda dei sistemi), e conservarli nel database affinch\u00e9 possano essere utilizzati successivamente.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a3ce55c3aec3eb93948150684838a5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa seconda sfida delle prestazioni riguarda la conservazione della storia. \u00c8 fondamentale mantenere i dati nel database e avere accesso rapido e comodo alle metriche raccolte per un determinato periodo. \u00c8 importante che questi dati possano essere facilmente ottenuti e utilizzati in report, grafici, trigger, soglie di valori per notifiche, ecc.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/325363d79f0270d620f956eeb8ab3402.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa terza sfida di prestazioni \u00e8 la pulizia della storia, ossia quando arriva il momento di eliminare dettagli metrici raccolti in un periodo lungo, come 5 anni (anche solo mesi o due mesi). Alcuni nodi di rete possono essere stati rimossi o alcuni host possono non essere pi\u00f9 necessari perch\u00e9 obsoleti e non raccolti. Tutto ci\u00f2 deve essere pulito affinch\u00e9 il database non si espanda eccessivamente. Inoltre, la pulizia della storia \u00e8 spesso una seria prova per il sistema di archiviazione e influisce notevolmente sulle prestazioni.<\/p>\n<h3>Come risolvere i problemi di caching?<\/h3>\n<p>\nOra parler\u00f2 specificamente di \u00abZabbix\u00bb. In \u00abZabbix\u00bb, le prime due sfide sono state affrontate attraverso il caching.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/d5510b31553ee8e63a0c240789d51622.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nRaccolta e trattamento dei dati \u2013 utilizziamo la memoria RAM per memorizzare tutti questi dati. Sar\u00e0 fornito maggiori dettagli su questi dati.<\/p>\n<p>Inoltre, sul lato del database esiste un caching per le selezioni principali \u2013 per i grafici e altre cose.<\/p>\n<p>Caching sul server Zabbix stesso: abbiamo ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Cosa sono?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/241a131145eccd280a7411c43b2cdce4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConfigurationCache \u2013 \u00e8 il principale cache in cui memorizziamo metriche, host, elementi di dati, trigger; tutto ci\u00f2 che serve per il pre-processing, la raccolta dei dati e le relative frequenze. Tutto questo \u00e8 conservato in ConfigurationCache per evitare richieste superflue al database. Dopo l'avvio del server, aggiorniamo (creiamo) questo cache e lo aggiorniamo periodicamente (in base alle impostazioni di configurazione).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/474ac0db2e46aa945a0da62197f72987.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Caching in Zabbix. Raccolta di dati<\/h3>\n<p>\nQui lo schema \u00e8 piuttosto ampio:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a6ad9dbd5deebac5440433a47c693fcf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI principali elementi nello schema sono questi raccoglitori:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/feb932586302e2284bd44595caf9ee1b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesti sono i processi di raccolta effettivi, diversi \u00abpoller\u00bb che rispondono a ogni tipo di raccolta. Raccolgono dati tramite icmp, ipmi, vari protocolli e li inviano per il pre-processing.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nInoltre, se abbiamo elementi di dati calcolati (chi \u00e8 a conoscenza di \u00abZabbix\u00bb lo sa), ossia elementi di dati calcolati e aggregati, li preleviamo direttamente da ValueCache. Di come viene popolato parler\u00f2 pi\u00f9 avanti. Tutti questi raccoglitori utilizzano ConfigurationCache per ottenere i loro compiti e successivamente trasmettono al pre-processing.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/3948ee1167c52856949c25e2043be974.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl pre-processing utilizza anche ConfigurationCache per ottenere i passaggi di pre-processing, elaborando questi dati in vari modi. A partire dalla versione 4.2, \u00e8 stato spostato sui proxy. Questo \u00e8 molto comodo, poich\u00e9 il pre-processing \u00e8 un'operazione piuttosto pesante. E se hai un grande sistema Zabbix, con molti elementi di dati e alta frequenza di raccolta, ci\u00f2 facilita notevolmente il lavoro.<\/p>\n<p>Di conseguenza, dopo aver elaborato questi dati in un certo modo tramite il pre-processing, li salviamo in HistoryCache per ulteriori elaborazioni. Qui termina la raccolta di dati. Passiamo al processo principale.<\/p>\n<h3>Funzionamento di History syncer<\/h3>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/66539e4184d041ed84f797080226ba24.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl processo principale in \u00abZabbix\u00bb (essendo un'architettura monolitica) \u00e8 il syncer della storia. Questo \u00e8 il processo principale che si occupa dell'elaborazione atomica di ogni elemento di dati, ovvero di ogni valore:<\/p>\n<ul>\n<li>riceve un valore (lo preleva dalla HistoryCache);<\/li>\n<li>verifica nel syncer della configurazione: ci sono trigger da calcolare? Se s\u00ec, li calcola;<br \/>\nse ci sono, crea eventi e genera un'escalation per inviare notifiche, se necessario secondo la configurazione;<\/li>\n<li>registra i trigger per un'elaborazione e aggregazione future; se aggreghi per l'ultima ora e cos\u00ec via, questo valore viene memorizzato in ValueCache, in modo da non dover accedere alla tabella della storia; in questo modo, ValueCache si riempie con i dati necessari per il calcolo dei trigger e degli elementi calcolati, ecc.;<\/li>\n<li>successivamente, il syncer della storia scrive tutti i dati nel database;<\/li>\n<li>il database li registra su disco: a questo punto il processo di elaborazione termina.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Database. Cache<\/h3>\n<p>\nDalla parte del database, quando desideri visualizzare grafici o report sugli eventi, ci sono varie cache. Ma in questo intervento non parler\u00f2 di esse.<\/p>\n<p>Per MySQL, c'\u00e8 Innodb_buffer_pool, e ci sono molte altre cache che possono essere configurate.<br \/>\nMa questi sono i principali:<\/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): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/925e7abb21cfaa2516ff2b33ab161dc0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPer tutti i database, ho indicato che ci sono determinate cache che consentono di mantenere in memoria operativa i dati spesso necessari per le query. Hanno le proprie tecnologie per farlo.<\/p>\n<h3>Sulle prestazioni del database<\/h3>\n<p>\nPertanto, esiste un ambiente competitivo, cio\u00e8 il server \u00abZabbix\u00bb raccoglie e registra i dati. Al riavvio, legge anche dalla storia per riempire ValueCache, e cos\u00ec via. Allo stesso tempo, potresti avere script e report che utilizzano l'API di \u00abZabbix\u00bb, che \u00e8 basata su un'interfaccia web. L'API di \u00abZabbix\u00bb accede al database e recupera i dati necessari per i grafici, i report o per un elenco di eventi o problemi recenti.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/10a55cb1af660aace3172a572bea6692.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUna soluzione molto popolare per la visualizzazione \u00e8 Grafana, che i nostri utenti utilizzano. Essa pu\u00f2 accedere direttamente sia tramite l'API di \u00abZabbix\u00bb che tramite il database. Crea anche una certa concorrenza per il recupero dei dati: \u00e8 necessaria una configurazione pi\u00f9 fine e adeguata del database per garantire un rapido rilascio dei risultati e i test.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/8a008e55dbee5635d386cec2fc1c40f5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Pulizia della storia. In Zabbix c'\u00e8 Housekeeper<\/h3>\n<p>\nIl terzo chiamato utilizzato in \u00abZabbix\u00bb \u00e8 la pulizia della storia tramite Housekeeper. L'\u00abHousekeeper\u00bb rispetta tutte le impostazioni, quindi abbiamo indicato negli elementi di dati quanti giorni conservare e quanti trend mantenere, la dinamica delle variazioni.<\/p>\n<p>Non ho parlato di TrendCache, che calcoliamo in tempo reale: i dati arrivano, li aggregiamo per un'ora (principalmente numeri dell'ultima ora), calcoliamo il valore medio\/minimo e li registriamo ogni ora nella tabella della dinamica delle variazioni (i \u00abTrend\u00bb). L'\u00abHousekeeper\u00bb viene avviato e rimuove i dati dal database con delle select, il che non \u00e8 sempre efficiente.<\/p>\n<p>Come capire che non \u00e8 efficiente? Puoi vedere sui grafici delle prestazioni dei processi interni un'immagine del genere:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/f413ec989491d4186a05c779978e2f6d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHai il syncer della storia costantemente occupato (grafico rosso). E il grafico 'arancione' che si muove sopra. Questo \u00e8 l'\u00abHousekeeper\u00bb, che si avvia e aspetta che il database rimuova tutte le righe che ha impostato.<\/p>\n<p>Prendiamo un qualche ID di elemento: bisogna rimuovere le ultime 5.000 righe; naturalmente, secondo gli indici. Ma di solito il dataset \u00e8 piuttosto grande - il database legge comunque da disco e solleva in cache, e questa \u00e8 un'operazione molto costosa per il database. A seconda delle dimensioni del database, ci\u00f2 pu\u00f2 portare a certi problemi di prestazioni.<\/p>\n<p>Disattivare l'\u00abHousekeeper\u00bb \u00e8 semplice: abbiamo l'interfaccia web, ben nota a tutti. Nelle impostazioni di Administration general (impostazioni per l'\u00abHousekeeper\u00bb) disattiviamo la gestione interna della storia e dei trend. Pertanto, l'\u00abHousekeeper\u00bb non gestir\u00e0 pi\u00f9 questo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/c9dc3ca86e7fd0c1229f6b9bc5d31270.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCosa si pu\u00f2 fare ulteriormente? Hai disattivato, i tuoi grafici si sono stabilizzati... Quali potrebbero essere i problemi successivi? Cosa pu\u00f2 aiutare?<\/p>\n<h3>Partizionamento<\/h3>\n<p>\nDi solito viene configurato in ogni database relazionale che ho menzionato, in modi diversi. MySQL ha la sua tecnologia. Ma in generale sono molto simili, se parliamo di PostgreSQL 10 e MySQL. Certamente, ci sono molte differenze interne su come tutto \u00e8 implementato e su come influisce sulle prestazioni. Ma in generale, la creazione di una nuova partizione porta spesso a certi problemi.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/729114d61794314e19383f09ee9b5d61.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA seconda della tua configurazione (quanto dati vengono generati in un giorno), di solito si imposta il minimo \u2013 cio\u00e8 1 giorno\/partizione, e per i \"trend\", la dinamica delle modifiche \u2013 1 mese \/ nuova partizione. Questo pu\u00f2 variare se hai una configurazione molto grande.<\/p>\n<p>Iniziamo con le dimensioni della configurazione: fino a 5.000 nuovi valori al secondo (note come nvps) sono considerate una piccola \"configurazione\". Una configurazione media \u00e8 tra 5 e 25.000 valori al secondo. Tutto ci\u00f2 che supera \u00e8 gi\u00e0 classificato come grandi e molto grandi installazioni, che richiedono una configurazione molto attenta del database stesso.<\/p>\n<p>In installazioni molto grandi, 1 giorno pu\u00f2 non essere ottimale. Ho visto personalmente partizioni di 40 gigabyte al giorno su MySQL (e possono essere anche pi\u00f9 grandi). Si tratta di un enorme volume di dati, che pu\u00f2 portare a diversi problemi. \u00c8 necessario ridurlo.<\/p>\n<h3>Perch\u00e9 \u00e8 necessario il partizionamento?<\/h3>\n<p>\nCosa offre il partizionamento, penso che tutti lo sappiano \u2013 si tratta della suddivisione delle tabelle. Spesso si tratta di file separati su disco e query span. Seleziona in modo pi\u00f9 ottimale una partizione se rientra nel normale partizionamento.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/4920fb3415733799f0a90b1bc7af0114.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPer \"Zabbix\", in particolare, si utilizza per range, cio\u00e8 usiamo un timestamp (un numero normale, tempo dall'inizio dell'epoca). Imposti l'inizio del giorno \/ la fine del giorno, e questo diventa una partizione. Pertanto, se richiedi dati risalenti a due giorni fa, tutto ci\u00f2 verr\u00e0 prelevato pi\u00f9 rapidamente dal database, perch\u00e9 deve semplicemente caricare un file in cache e fornirlo (e non una grande tabella).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/f5ee4e0b471eb5ebe701615aa617d66d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMolti database accelerano anche l'inserimento (nella child-table). Finora ho parlato in modo astratto, ma \u00e8 possibile anche questo. Spesso il partizionamento aiuta.<\/p>\n<h3>Elasticsearch per NoSQL<\/h3>\n<p>\nRecentemente, nella versione 3.4, abbiamo implementato una soluzione per NoSQL. Abbiamo aggiunto la possibilit\u00e0 di scrivere in Elasticsearch. Puoi scrivere tipi di dati diversi: scegli \u2013 scrivi numeri oppure segni; abbiamo stringhe di testo, log che puoi scrivere in Elasticsearch\u2026 Di conseguenza, anche l'interfaccia web acceder\u00e0 a Elasticsearch. Questo funziona molto bene in alcuni casi, ma al momento pu\u00f2 essere utilizzato.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/24fe7d19c9e42474cd786ba59846c18c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB. Hyper-tables<\/h3>\n<p>\nPer la versione 4.4.2 abbiamo notato una cosa riguardo a TimescaleDB. Che cos'\u00e8? \u00c8 un'estensione per \"Postgres\", quindi ha un'interfaccia nativa PostgreSQL. Inoltre, questa estensione permette di lavorare in modo molto pi\u00f9 efficiente con i dati time-series e dispone di partizionamento automatico. Ecco come appare:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/de921f06453476215b6240ab9da6fae1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesta \u00e8 un'hypertable \u2013 esiste un concetto in Timescale. \u00c8 un'hypertable che crei, e contiene chunk (chunk). I chunk sono partizioni, sono child-tables, se non erro. Questo \u00e8 davvero efficiente.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/719eb3f5d8c9f57544dfc4010850610c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB e PostgreSQL<\/h3>\n<p>\nCome affermano i produttori di TimescaleDB, utilizzano un algoritmo di elaborazione delle query pi\u00f9 efficace, in particolare per gli insert, che consente di avere prestazioni pressoch\u00e9 costanti all'aumentare della dimensione del dataset di inserimento. Cio\u00e8, dopo 200 milioni di righe, \"Postgres\" normale inizia a scendere drasticamente e perde letteralmente fino a zero prestazioni, mentre \"Timescale\" consente di inserire dati in modo molto efficace indipendentemente dalla quantit\u00e0.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a613d505a9dfe6008551ce981da7b24e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Come installare TimescaleDB? \u00c8 molto semplice!<\/h3>\n<p>\n\u00c8 descritto nella documentazione \u2013 puoi installarlo dai pacchetti per qualsiasi\u2026 Dipende dai pacchetti ufficiali di \"Postgres\". Puoi compilarlo manualmente. Cos\u00ec \u00e8 successo che ho dovuto compilarlo per il database.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/6767927fa92260103d318f9aa70ef5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSu \"Zabbix\", attiviamo semplicemente l'estensione. Penso che chiunque abbia usato l'estensione in \"Postgres\"\u2026 Attivi semplicemente l'estensione, crei quella per il database \"Zabbix\" che stai utilizzando.<\/p>\n<p>E l'ultimo passo\u2026<\/p>\n<h3>TimescaleDB. Migrazione delle tabelle storiche<\/h3>\n<p>\nDevi creare un'hypertable. Per questo c'\u00e8 una funzione speciale \u2013 Create hypertable. In questo caso, come primo parametro, indichi la tabella che deve essere presente nel database (per la quale deve essere creata l'hypertable).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/47350f79fd9829c12685c1df8f0ff9a6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl campo su cui deve essere creato e chunk_time_interval (questo \u00e8 l'intervallo dei chunk (partizioni) da utilizzare). 86.400 \u2013 \u00e8 un giorno. <\/p>\n<p>Il parametro migrate_data: se imposti su true, trasferisce tutti i dati correnti nei chunk gi\u00e0 creati.<\/p>\n<p>Ho utilizzato migrate_data \u2013 richiede un tempo considerevole, a seconda delle dimensioni del tuo database. Avevo pi\u00f9 di un terabyte \u2013 la creazione ha richiesto pi\u00f9 di un'ora. In alcuni casi, durante il test, ho eliminato i dati storici per il testo (history_text) e la stringa (history_str), per evitare di trasferire \u2013 in realt\u00e0 non mi interessavano.<\/p>\n<p>L'ultimo aggiornamento che facciamo nel nostro db_extension: stiamo installando timescaledb, affinch\u00e9 il database e, in particolare, il nostro \u00abZabbix\u00bb, comprendano l'esistenza di db_extension. Attiva e utilizza correttamente la sintassi e le query per il database, sfruttando gi\u00e0 le \u00abfunzionalit\u00e0\u00bb necessarie per TimescaleDB.<\/p>\n<h3>Configurazione del server<\/h3>\n<p>\nHo utilizzato due server. Il primo server \u00e8 una macchina virtuale piuttosto piccola, con 20 processori e 16 gigabyte di RAM. Ho installato PostgreSQL 10.8 su di essa:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/990805374a2380a5c645c578404489bd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl sistema operativo era Debian, il file system \u2013 xfs. Ho effettuato impostazioni minime per utilizzare specificamente questo database, a parte ci\u00f2 che utilizzer\u00e0 il \u00abZabbix\u00bb. Sulla stessa macchina c'erano il server \u00abZabbix\u00bb, PostgreSQL e agenti di carico.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a6efa9ab9cd58f0061d04f13fe31018c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHo impiegato 50 agenti attivi, che utilizzano LoadableModule per generare rapidamente risultati diversi. Sono stati generati stringhe, numeri e cos\u00ec via. Ho riempito il database con una grande quantit\u00e0 di dati. Inizialmente la configurazione conteneva 5.000 elementi di dati per ogni host, e circa ogni elemento di dati includeva un trigger, affinch\u00e9 fosse una configurazione reale. A volte, per l'utilizzo \u00e8 necessario anche pi\u00f9 di un trigger.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/d5a3c306402e08bf2532eb6203a4aab4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL'intervallo di aggiornamento e il carico stesso lo regolavo non solo utilizzando 50 agenti (aggiungevo anche altri), ma grazie a elementi di dati dinamici e riducendo l'intervallo di aggiornamento a 4 secondi.<\/p>\n<h3>Test di prestazioni. PostgreSQL: 36.000 NVPs<\/h3>\n<p>\nLa prima esecuzione, il primo setup era su un PostgreSQL 10 pulito su questa macchina (35.000 valori al secondo). In generale, come si pu\u00f2 vedere sullo schermo, l'inserimento dei dati richiede frazioni di secondo \u2013 va tutto bene e veloce, con dischi SSD (200 gigabyte). L'unico problema \u00e8 che 20 GB si riempiono piuttosto rapidamente.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/6803a64fedd26093b9117a036d2993ae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCi saranno molti di questi grafici in seguito. Questo \u00e8 il dashboard di prestazioni standard del server \u00abZabbix\u00bb.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/081cc11c6bf42db3f8f16b6cc4e6ee0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl primo grafico mostra il numero di valori al secondo (blu, in alto a sinistra), 35.000 valori in questo caso. Questo (in alto al centro) \u00e8 il carico dei processi di raccolta, e questo (in alto a destra) \u00e8 il carico dei processi interni: history syncers e housekeeper, che qui (in basso al centro) ha operato per un tempo considerevole.<\/p>\n<p>Questo grafico (in basso al centro) mostra l'uso di ValueCache \u2013 quanti hit di ValueCache per i trigger (alcuni migliaia di valori al secondo). Un grafico importante \u00e8 il quarto (in basso a sinistra), che mostra l'uso di HistoryCache, di cui ho parlato, che \u00e8 un buffer prima dell'inserimento nel database.<\/p>\n<h3>Test di prestazioni. PostgreSQL: 50.000 NVPs<\/h3>\n<p>\nSuccessivamente ho aumentato il carico a 50.000 valori al secondo su questa stessa macchina. Con il caricamento da parte di \u00abHousekeeper\u00bb, 10.000 valori venivano gi\u00e0 registrati in 2-3 secondi con calcolo. Questo \u00e8 evidenziato nello screenshot seguente:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/80824da986dbee2f8d5ebe0ead4fbcfd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00abHousekeeper\u00bb inizia a interferire con il lavoro, ma in generale il carico dei trapper history-syncers \u00e8 ancora al livello del 60% (terzo grafico, in alto a destra). HistoryCache inizia a riempirsi attivamente durante il funzionamento di \u00abHousekeeper\u00bb (in basso a sinistra). Era circa mezzo gigabyte, riempito al 20%.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/9e1bcd4f3b9f3e8a1c9a36b2083ec61b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Test di prestazioni. PostgreSQL: 80.000 NVPs<\/h3>\n<p>\nHo poi aumentato fino a 80.000 valori al secondo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/13ae1589d6b9d35b4dda9c6c7d989cc2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nErano circa 400.000 elementi di dati, 280.000 trigger. Come potete vedere, l'inserimento, in base al carico degli history-syncers (ce n'erano 30), era gi\u00e0 piuttosto alto. Ho continuato ad aumentare diversi parametri: history-syncers, cache\u2026 Su questa macchina il carico degli history-syncers ha iniziato ad aumentare al massimo, praticamente \u00abin punteggio\u00bb, portando a un carico di HistoryCache molto elevato:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/0ec528256c8fa7b16e1c7c95c8119535.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDurante tutto questo tempo ho monitorato tutti i parametri di sistema (come l'uso della CPU, della RAM) e ho scoperto che l'utilizzo dei dischi era massimo \u2013 ho raggiunto la massima capacit\u00e0 di questo disco su questa macchina virtuale. PostgreSQL ha iniziato a scaricare dati con abbastanza intensit\u00e0 e il disco non era pi\u00f9 in grado di scrivere e leggere...<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/0809dbd7638e7ee003ea24c611984a0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHo preso un altro server, che aveva gi\u00e0 48 processori e 128 gigabyte di RAM:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/53410b502a4574aac5d40f1a2a6d3f42.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHo anche ottimizzato questo server \u2013 ho installato 60 history syncers e ho raggiunto prestazioni accettabili. Non siamo esattamente \u00abin punteggio\u00bb, ma \u00e8 probabilmente il limite delle prestazioni, dove \u00e8 necessario intervenire.<\/p>\n<h3>Test di prestazioni. TimescaleDB: 80.000 NVPs<\/h3>\n<p>\nAvevo come obiettivo principale \u2013 utilizzare TimescaleDB. In ogni grafico si vede un calo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/b0064068895a34b93b5aa6771aba05cb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesti fallimenti sono proprio la migrazione dei dati. Dopo di che, nel server Zabbix, il profilo di caricamento degli storici dei sincronizzatori, come potete vedere, \u00e8 cambiato notevolmente. Ora consente di inserire dati quasi tre volte pi\u00f9 velocemente e utilizza meno HistoryCache \u2013 quindi i dati vi arriveranno puntualmente. Ancora una volta, 80 mila valori al secondo \u00e8 un tasso piuttosto elevato (ovviamente, non per Yandex). In generale, si tratta di un setup piuttosto grande, con un server.<\/p>\n<h3>Test di prestazioni PostgreSQL: 120 mila NVP.<\/h3>\n<p>\nDopo ho aumentato il numero di elementi dati a mezzo milione e ho ottenuto un valore stimato di 125 mila al secondo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/7d0cf2ef7c6691c1bbf4b90afd34e4bb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE ho ottenuto questi grafici:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/9c09333a50e016921a8a5b70e00397a1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn linea di massima si tratta di un setup funzionante, pu\u00f2 lavorare per lungo tempo. Ma poich\u00e9 avevo un disco di solo 1,5 terabyte, l'ho esaurito in pochi giorni. La cosa pi\u00f9 importante \u00e8 che allo stesso tempo venivano create nuove partizioni su TimescaleDB, e questo per le prestazioni avveniva in modo totalmente invisibile, a differenza di MySQL.<\/p>\n<p>Di solito le partizioni vengono create di notte, perch\u00e9 questo blocca del tutto l'inserimento e il lavoro con le tabelle, e pu\u00f2 portare a una degradazione del servizio. In questo caso non c'\u00e8 nulla di tutto ci\u00f2! L'obiettivo principale era verificare le capacit\u00e0 di TimescaleDB. Ho ottenuto questo numero: 120 mila valori al secondo.<\/p>\n<p>Ci sono anche esempi nella comunit\u00e0:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/66aa6b1d4c559d12082e4d91b6a1ca10.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUna persona ha attivato TimescaleDB e il caricamento per utilizzo di io.weight \u00e8 diminuito sulla CPU; e l'utilizzo degli elementi dei processi interni \u00e8 sceso anche grazie all'attivazione di TimescaleDB. Inoltre, si trattava di dischi normali, ovvero una normale virtual machine su dischi comuni (non SSD)!<\/p>\n<p>Per piccoli setup che si scontrano con le prestazioni del disco, TimescaleDB \u00e8, a mio avviso, una soluzione molto valida. Permetter\u00e0 di continuare a lavorare fino a quando non si migrer\u00e0 su hardware pi\u00f9 veloce per il database.<\/p>\n<p>Invito tutti voi ai nostri eventi: Conferenza \u2013 a Mosca, Summit \u2013 a Riga. Utilizzate i nostri canali \u2013 Telegram, forum, IRC. Se avete domande, veniteci a trovare allo stand, possiamo parlare di tutto.<\/p>\n<h3>Domande dal pubblico<\/h3>\n<p>\nDomanda dal pubblico (di seguito \u2013 A): \u2013 Se TimescaleDB \u00e8 cos\u00ec facile da configurare e fornisce un aumento delle prestazioni, potrebbe valere la pena utilizzarlo come best practice per configurare Zabbix con PostgreSQL? E ci sono insidie o svantaggi in questa soluzione, o se decido di utilizzare Zabbix, posso tranquillamente prendere PostgreSQL, installare Timescale immediatamente, utilizzarlo e non preoccuparmi di alcun problema?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/314845a019724806283a957b15d857cc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>AG:<\/b> \u2013 S\u00ec, direi che \u00e8 un'ottima raccomandazione: utilizzare PostgreSQL subito con l'estensione TimescaleDB. Come ho gi\u00e0 detto, ci sono molte recensioni positive, nonostante questa funzione sia sperimentale. Ma in realt\u00e0 i test mostrano che \u00e8 una soluzione eccellente (con TimescaleDB), e credo che continuer\u00e0 a svilupparsi! Seguiamo come si evolve questa estensione e gestiremo ci\u00f2 che \u00e8 necessario.<\/p>\n<p>Durante lo sviluppo ci siamo basati su una loro nota funzione: l\u00e0 si poteva lavorare con i chunk in modo un po' diverso. Ma poi l'hanno rimosso nella versione successiva, e abbiamo dovuto smettere di basarci su quel codice. Consiglierei di utilizzare questa soluzione su molti setup. Se usate MySQL\u2026 Per setup di dimensioni medie qualsiasi soluzione funziona bene.<\/p>\n<p><b>A:<\/b> \u2013 Negli ultimi grafici, che provengono dalla comunit\u00e0, c'era un grafico con Housekeeper:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/d01549b6b9b97d8bdf5372efe05d9039.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHa continuato a funzionare. Cosa fa Housekeeper nel caso di TimescaleDB?<\/p>\n<p><b>AG:<\/b> \u2013 Al momento non posso dirlo con certezza \u2013 esaminer\u00f2 il codice e fornir\u00f2 informazioni pi\u00f9 dettagliate. Usa query specifiche di TimescaleDB non per eliminare i chunk, ma per aggregare in qualche modo. Non sono pronto a rispondere a questa domanda tecnica. Lo chiariremo oggi o domani allo stand.<\/p>\n<p><b>A:<\/b> \u2013 Ho una domanda simile \u2013 riguardo alle prestazioni dell'operazione di eliminazione in Timescale.<br \/>\nA (risposta dal pubblico): \u2013 Quando si eliminano dati da una tabella, se si utilizza il delete, \u00e8 necessario scorrere la tabella \u2013 eliminare, pulire, segnare tutto per la futura vacuum. In Timescale, poich\u00e9 si hanno chunk, si pu\u00f2 semplicemente droppare. In sostanza, si dice semplicemente al file che si trova nei big data: \u00abElimina!\u00bb<\/p>\n<p>Timescale capisce semplicemente che quel chunk non esiste pi\u00f9. E poich\u00e9 si integra nel pianificatore delle query, cattura le vostre condizioni nel select o in altre operazioni e comprende immediatamente che quel chunk non esiste pi\u00f9 \u2013 \u00abNon andr\u00f2 l\u00ec!\u00bb (i dati sono assenti). Ecco tutto! Quindi la scansione della tabella viene sostituita dall'eliminazione di un file binario, perci\u00f2 \u00e8 veloce.<\/p>\n<p><b>A:<\/b> \u2013 Abbiamo gi\u00e0 toccato l'argomento non SQL. Da quanto ho capito, a \u00abZabbix\u00bb non serve molto modificare i dati, e tutto ci\u00f2 \u00e8 simile a un log. \u00c8 possibile utilizzare database specializzati che non possono modificare i loro dati, ma che al contempo sono molto pi\u00f9 veloci nel salvare, accumulare e restituire \u2013 Clickhouse, per esempio, qualcosa di tipo Kafka?.. Kafka \u00e8 anch'esso un log! Possono essere integrati in qualche modo?<\/p>\n<p><b>AG:<\/b> \u2013 \u00c8 possibile effettuare l'export. Abbiamo una certa \u00abfeature\u00bb dalla versione 3.4: puoi scrivere in file tutti i file storici, eventi e tutto il resto; e poi inviare a qualsiasi altro DB con un certo elaboratore. In effetti, molte persone modificano e scrivono direttamente nel DB. Gli history-sinkers li scrivono in file al volo, ruotano questi file e cos\u00ec via, e puoi trasferirli in \u00abClickhouse\u00bb. Non posso dire quali siano i piani, ma \u00e8 possibile che il supporto per le soluzioni NoSQL (come \u00abClickhouse\u00bb) continuer\u00e0.<\/p>\n<p><b>A:<\/b> \u2013 Quindi, \u00e8 possibile liberarsi completamente da postgres?<\/p>\n<p><b>AG:<\/b> \u2013 Certamente, la parte pi\u00f9 complessa in \u00abZabbix\u00bb sono le tabelle storiche, che creano pi\u00f9 problemi, e gli eventi. In questo caso, se non si conservano a lungo gli eventi e si mantiene la storia con le tendenze in un altro storage veloce, in generale non ci dovrebbero essere problemi.<\/p>\n<p><b>A:<\/b> \u2013 Puoi valutare quanto sarebbe pi\u00f9 veloce tutto se ci si trasferisse a \u00abClickhouse\u00bb, per esempio?<\/p>\n<p><b>AG:<\/b> \u2013 Non ho testato. Penso che si possano raggiungere almeno le stesse cifre piuttosto facilmente, considerando che \u00abClickhouse\u00bb ha la sua interfaccia, ma non posso dirlo con certezza. \u00c8 meglio testare. Tutto dipende dalla configurazione: quante macchine hai e cos\u00ec via. L'inserimento \u00e8 una cosa, ma bisogna anche recuperare i dati \u2013 con Grafana o altro.<\/p>\n<p><b>A:<\/b> \u2013 Quindi si tratta di una battaglia equa, e non di un grande vantaggio di questi DB veloci?<\/p>\n<p><b>AG:<\/b> \u2013 Penso che quando integriamo, avremo test pi\u00f9 accurati.<\/p>\n<p><b>A:<\/b> \u2013 E dove \u00e8 finito il vecchio buon RRD? Cosa ha spinto a passare ai database SQL? Inizialmente tutte le metriche venivano raccolte su RRD.<\/p>\n<p><b>AG:<\/b> \u2013 In \u00abZabbix\u00bb RRD potrebbe essere stato presente in una versione molto antica. Sono sempre esistiti database SQL \u2013 l'approccio classico. L'approccio classico \u00e8 MySQL, PostgreSQL (esistono da molto tempo). Abbiamo un'interfaccia comune per i database SQL e praticamente non abbiamo mai utilizzato RRD.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): elevate prestazioni e partizionamento nativo\" 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=\"Riproduci video\" 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>Un po' di pubblicit\u00e0 \ud83d\ude42<\/h3>\n<p>\nGrazie per essere con noi. Ti piacciono i nostri articoli? Vuoi vedere pi\u00f9 contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci ai tuoi conoscenti, <noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/cloudvps\/nl\">VPS cloud per sviluppatori a partire da $4,99<\/a><\/noindex>, <b>un'alternativa unica ai server entry-level, che abbiamo creato per te:<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/347386\/\">Tutta la verit\u00e0 su VPS (KVM) E5-2697 v3 (6 Core) 10GB DDR4 480GB SSD 1Gbps a partire da $19. Come dividere il server correttamente?<\/a><\/noindex> (disponibili opzioni con RAID1 e RAID10, fino a 24 core e fino a 40GB DDR4).<\/p>\n<p><b>Dell R730xd a met\u00e0 prezzo nel data center Equinix Tier IV ad Amsterdam?<\/b> Solo da noi <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 a partire da $199<\/a><\/noindex> nei Paesi Bassi! <b>Dell R420 \u2014 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 a partire da $99!<\/b><\/b> Scopri di pi\u00f9 su <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">Come costruire un'infrastruttura di classe enterprise con server Dell R730xd E5-2650 v4 dal costo di 9000 euro a prezzi stracciati?<\/a><\/noindex><br \/>\n<br \/>Fonte: <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.0.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\/it\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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\/it\/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++, Andrea Guccin (Zabbix): prestazioni elevate e partizionamento nativo | ProHoster","description":"Esamineremo il funzionamento di Zabbix con TimescaleDB come backend. Mostreremo come avviarlo da zero e come migrare da PostgreSQL.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/55734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=55734"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/55734\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=55734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=55734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=55734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}