{"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): alte 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 avviarlo da zero e come migrare da PostgreSQL. Presenteremo inoltre test comparativi delle performance delle due configurazioni.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 \"Tomsk\". 24 giugno, 16:00. Tesi 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 un ingegnere di supporto tecnico di ZABBIX (di seguito \u2013 \"Zabbix\"), formatore. Lavoro da oltre 6 anni nel supporto tecnico e mi sono occupato direttamente delle performance. Oggi parler\u00f2 delle performance che TimescaleDB pu\u00f2 fornire, in confronto con il comune PostgreSQL 10. Cuore della presentazione sar\u00e0 anche una parte introduttiva \u2013 su come funziona in generale.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Le principali sfide delle performance: dalla raccolta alla pulizia dei dati<\/h3>\n<p>\nIniziamo col dire che ci sono determinate sfide delle performance con cui ogni sistema di monitoraggio si confronta. La prima sfida delle performance \u00e8 la rapida raccolta e elaborazione dei dati.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 secondo le espressioni di trigger, cio\u00e8 elaborare in base a determinati criteri (che variano da sistema a sistema) e archiviarli nel database, in modo da poterli utilizzare successivamente.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 performance \u00e8 lo stoccaggio della storia. \u00c8 fondamentale conservare i dati nel database e avere accesso rapido e conveniente a queste metriche raccolte in un certo periodo di tempo. L'importante \u00e8 poter ottenere facilmente questi dati e utilizzarli nei report, nei grafici, nei trigger e nei valori soglia, per le notifiche, ecc.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/325363d79f0270d620f956eeb8ab3402.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa terza sfida delle performance \u00e8 la pulizia della storia, cio\u00e8 quando arriva il momento in cui non \u00e8 pi\u00f9 necessario conservare metriche dettagliate raccolte per 5 anni (anche solo per mesi o due mesi). Alcuni nodi della rete sono stati rimossi, o alcuni host, e le metriche non sono pi\u00f9 necessarie perch\u00e9 sono diventate obsolete e non vengono pi\u00f9 raccolte. Tutto questo deve essere rimosso per evitare che il database cresca eccessivamente. Inoltre, la pulizia della storia \u00e8 spesso una seria prova per l'archiviazione, influenzando notevolmente le performance.<\/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 chiamate sono risolte tramite caching.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/d5510b31553ee8e63a0c240789d51622.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nRaccolta e elaborazione dei dati \u2013 utilizziamo la memoria RAM per memorizzare tutti questi dati. A breve verr\u00e0 fornito un approfondimento su questi dati.<\/p>\n<p>C'\u00e8 anche un certo caching sul lato del database per le selezioni principali \u2013 per i grafici e altre cose.<\/p>\n<p>Caching sul lato del server Zabbix stesso: abbiamo ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Che cos'\u00e8?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/241a131145eccd280a7411c43b2cdce4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConfigurationCache \u00e8 la cache principale in cui memorizziamo metriche, host, elementi di dati, trigger; tutto ci\u00f2 che \u00e8 necessario per l'elaborazione del preprocessing, la raccolta dei dati, da quali host raccogliere e con quale frequenza. Tutto questo \u00e8 memorizzato in ConfigurationCache, per evitare di dover accedere al database e creare richieste inutili. Dopo l'avvio del server, aggiorniamo questa cache (creiamo) e la aggiorniamo periodicamente (in base alle impostazioni di configurazione).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 dei dati<\/h3>\n<p>\nQui lo schema \u00e8 abbastanza grande:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a6ad9dbd5deebac5440433a47c693fcf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI principali nello schema sono questi raccoglitori:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/feb932586302e2284bd44595caf9ee1b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSono i processi di raccolta stessi, diversi \"poller\", che sono responsabili di diversi tipi di raccolta. Raccolgono dati tramite icmp, ipmi e vari protocolli e trasferiscono tutto questo al preprocessing.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nInoltre, se abbiamo elementi di dati calcolati (chi \u00e8 familiare con \u00abZabbix\u00bb lo sa), ci sono elementi di dati calcolati e aggregati, li preleviamo direttamente da ValueCache. Spiegher\u00f2 pi\u00f9 avanti come viene riempita. Tutti questi raccoglitori utilizzano ConfigurationCache per ottenere i propri compiti e poi trasferiscono al preprocessing.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/3948ee1167c52856949c25e2043be974.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl preprocessing utilizza anche ConfigurationCache per ottenere i passaggi di preprocessing, elaborando questi dati in vari modi. A partire dalla versione 4.2, \u00e8 stato spostato sul proxy. \u00c8 molto comodo, perch\u00e9 il preprocessing \u00e8 un'operazione piuttosto pesante. E se hai un \u00abZabbix\u00bb molto grande, con un elevato numero di elementi di dati e alta frequenza di raccolta, questo facilita notevolmente il lavoro.<\/p>\n<p>Di conseguenza, dopo aver elaborato questi dati in un certo modo tramite il preprocessing, li salviamo in HistoryCache per ulteriori elaborazioni. Qui termina la raccolta dei dati. Passiamo al processo principale.<\/p>\n<h3>Funzione di sincronizzazione della cronologia<\/h3>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 (dato che ha un'architettura monolitica) \u00e8 l'History syncer. Questo \u00e8 il processo principale che si occupa dell'elaborazione atomica di ogni singolo elemento di dati, ovvero di ogni valore:<\/p>\n<ul>\n<li>arriva un valore (lo prende da HistoryCache);<\/li>\n<li>controlla nel Configuration syncer: ci sono trigger per il calcolo? Li calcola;<br \/>\nse ci sono, crea eventi, crea un'escalation per generare una notifica se necessario in base alla configurazione;<\/li>\n<li>registra i trigger per elaborazioni e aggregazioni future; se aggrega nell'ultima ora e cos\u00ec via, questo valore viene memorizzato in ValueCache, per non dover accedere alla tabella storica; in questo modo, ValueCache si riempie di dati necessari per il calcolo dei trigger, degli elementi calcolati, ecc.;<\/li>\n<li>successivamente, l'History syncer scrive tutti i dati nel database;<\/li>\n<li>il database li scrive su disco \u2013 a questo punto, il processo di elaborazione termina.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Database. Caching<\/h3>\n<p>\nDalla parte del DB, quando vuoi visualizzare grafici o report sugli eventi, ci sono diversi cache. Ma nel contesto di questa relazione, non parler\u00f2 di essi.<\/p>\n<p>Per MySQL c'\u00e8 Innodb_buffer_pool, oltre a un mucchio di vari cache che possono anche essere configurati.<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): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/925e7abb21cfaa2516ff2b33ab161dc0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHo portato per tutti i database che ci sono certi cache, che permettono di mantenere in memoria i dati che sono frequentemente necessari per le query. L\u00ec hanno le loro tecnologie per questo.<\/p>\n<h3>Sulle prestazioni del database<\/h3>\n<p>\nDi conseguenza, c'\u00e8 un ambiente concorrente, cio\u00e8 il server \u00abZabbix\u00bb raccoglie e registra dati. Al riavvio, legge anche dalla storia per riempire ValueCache e cos\u00ec via. Allo stesso tempo, ci possono essere script e report che utilizzano l\u2019API di \u00abZabbix\u00bb, costruita sulla base dell'interfaccia web. L\u2019API di \u00abZabbix\u00bb accede al DB e ottiene i dati necessari per ottenere grafici, report o qualche lista di eventi e problemi recenti.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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, utilizzata dai nostri utenti. \u00c8 in grado di accedere direttamente sia tramite l\u2019API di \u00abZabbix\u00bb che attraverso il DB. Essa crea anche una certa concorrenza per ottenere dati: \u00e8 necessaria una configurazione pi\u00f9 fine e buona del DB per garantire risultati rapidi e test.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 cronologia. In Zabbix c'\u00e8 il Housekeeper<\/h3>\n<p>\nIl terzo chiamato utilizzato in \u00abZabbix\u00bb \u00e8 la pulizia della cronologia tramite il Housekeeper. Il \u00abHousekeeper\u00bb rispetta tutte le impostazioni, ovvero abbiamo negli elementi dati indicato per quanto tempo conservare (in giorni), quanto conservare i trend, la dinamica delle variazioni.<\/p>\n<p>Non ho parlato del TrendCache, che calcoliamo al volo: arrivano dati, li aggregiamo per un'ora (principalmente si tratta di numeri dell'ultima ora), la quantit\u00e0 media \/ minima e li registriamo un'ora in tabella della dinamica delle variazioni (\u00abTrends\u00bb). Il \u00abHousekeeper\u00bb viene avviato e rimuove dati dal DB con semplici select, il che non \u00e8 sempre efficiente.<\/p>\n<p>Come capire che non \u00e8 efficiente? Puoi vedere nei grafici delle prestazioni dei processi interni un quadro del genere:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/f413ec989491d4186a05c779978e2f6d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHai il History syncer costantemente occupato (grafico rosso). E il grafico \u00abarancione\u00bb che va sopra. Questo \u00e8 il \u00abHousekeeper\u00bb, che viene avviato e aspetta dal DB quando rimuover\u00e0 tutte le righe che ha specificato.<\/p>\n<p>Prendiamo un qualsiasi Item ID: \u00e8 necessario eliminare le ultime 5.000; certo, per gli indici. Ma di solito il dataset \u00e8 piuttosto grande \u2013 il database lo legge comunque dal disco e lo carica in cache, e questa \u00e8 un'operazione molto costosa per il DB. A seconda delle sue dimensioni, pu\u00f2 portare a determinati problemi di prestazioni.<\/p>\n<p>Disabilitare il \u00abHousekeeper\u00bb pu\u00f2 essere fatto in modo semplice \u2013 abbiamo l'interfaccia web che tutti conosciamo. Nelle impostazioni in Administration general (impostazioni per il \u00abHousekeeper\u00bb) disattiviamo il housekeeping interno per la cronologia e i trend interni. Di conseguenza, il \u00abHousekeeper\u00bb non gestisce pi\u00f9 questo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 dopo? Hai disabilitato, i tuoi grafici si sono allineati\u2026 Quali problemi possono sorgere dopo? Cosa pu\u00f2 aiutare?<\/p>\n<h3>Partizionamento (sezionamento)<\/h3>\n<p>\nDi solito viene configurato in ogni database relazionale che ho elencato, in modi diversi. MySQL ha la sua tecnologia. Ma in generale sono molto simili, se si parla di PostgreSQL 10 e MySQL. Certo, ci sono molte differenze interne su come tutto questo \u00e8 implementato e come influisce sulle prestazioni. Ma in generale, la creazione di una nuova partizione porta spesso anche a determinati problemi.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/729114d61794314e19383f09ee9b5d61.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA seconda del vostro setup (quanti dati vengono creati in un giorno), di solito si imposta il minimo - 1 giorno \/ partizione, e per i \u00abtrend\u00bb, la dinamica delle variazioni - 1 mese \/ nuova partizione. Questo pu\u00f2 cambiare se avete un setup molto grande.<\/p>\n<p>Fammi subito parlare delle dimensioni del setup: fino a 5.000 nuovi valori al secondo (nvps, come si dice) - questo sar\u00e0 considerato un piccolo \u00absetup\u00bb. Medio - da 5 a 25.000 valori al secondo. Qualunque cosa oltre - sono gi\u00e0 installazioni grandi e molto grandi, che richiedono una configurazione molto attenta del database.<\/p>\n<p>In installazioni molto grandi, 1 giorno potrebbe non essere ottimale. Ho visto personalmente in MySQL partizioni da 40 gigabyte al giorno (e possono essere anche pi\u00f9 grandi). Questo \u00e8 un volume di dati molto grande che pu\u00f2 portare a qualche problema. Bisogna ridurlo.<\/p>\n<h3>A cosa serve la partizione?<\/h3>\n<p>\nCosa fa il Partitioning, penso che tutti lo sappiano - \u00e8 la suddivisione delle tabelle. Spesso si tratta di file separati sul disco e query span. Seleziona in modo pi\u00f9 ottimale una partizione, se rientra nella normale partizione.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/4920fb3415733799f0a90b1bc7af0114.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPer \u00abZabbix\u00bb, in particolare, viene utilizzato per intervallo, cio\u00e8 utilizziamo il timestamp (un numero ordinario, il tempo dall'inizio dell'epoca). Imposti l'inizio della giornata \/ la fine della giornata e questo diventa una partizione. Dunque, se richiedi dati di un giorno fa, tutto viene estratto dal database pi\u00f9 rapidamente, perch\u00e9 occorre solo caricare un file in cache e fornire (e non una tabella grande).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/f5ee4e0b471eb5ebe701615aa617d66d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMolti DB accelerano anche l'inserimento (inserimento in una tabella figlia). Finora parlo in astratto, ma \u00e8 possibile. La partizione spesso aiuta.<\/p>\n<h3>Elasticsearch per NoSQL<\/h3>\n<p>\nRecentemente, nella 3.4, abbiamo implementato una soluzione per NoSQL. Abbiamo aggiunto la possibilit\u00e0 di scrivere in Elasticsearch. Puoi scrivere alcuni tipi separati: scegli - o scrivi numeri, o qualche segno; abbiamo stringa-testo, puoi scrivere log in Elasticsearch\u2026 Dunque, l'interfaccia web si interfaccer\u00e0 gi\u00e0 con Elasticsearch. Questo funziona ottimamente in alcuni casi, ma al momento \u00e8 utilizzabile.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/24fe7d19c9e42474cd786ba59846c18c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB. I ipertabelle<\/h3>\n<p>\nPer la 4.4.2 abbiamo notato una cosa, come TimescaleDB. Cos'\u00e8? \u00c8 un'estensione per PostgreSQL, quindi ha un'interfaccia nativa di PostgreSQL. Inoltre, questa estensione consente di lavorare in modo molto pi\u00f9 efficiente con i dati di tipo timeseries e ha partizionamento automatico. Ecco come appare:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/de921f06453476215b6240ab9da6fae1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesto \u00e8 un hypertable \u2013 \u00e8 un concetto in Timescale. \u00c8 la tabella ibrida che crei, e dentro ci sono i chunk (chunk). I chunk sono le partizioni, sono tabelle figlio, se non erro. \u00c8 davvero efficace.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 corretto, in particolare per gli insert, che consente di mantenere una prestazione pressoch\u00e9 costante con l'aumento della dimensione del dataset di inserimento. Quindi, dopo 200 milioni di righe, PostgreSQL normale inizia a calare drasticamente e perde letteralmente prestazione fino a zero, mentre Timescale consente di inserire i dati il pi\u00f9 efficacemente possibile con qualsiasi quantit\u00e0 di dati.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 semplice!<\/h3>\n<p>\n\u00c8 descritto nella sua documentazione \u2013 puoi installarlo dai pacchetti per qualsiasi\u2026 Dipende dai pacchetti ufficiali di PostgreSQL. Puoi compilarlo a mano. \u00c8 capitato che dovessi compilarlo per il DB.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/6767927fa92260103d318f9aa70ef5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn Zabbix attiviamo semplicemente l'Extention. Penso che chi ha usato l'Extention in PostgreSQL\u2026 Attivate semplicemente l'Extention, la create per il DB di Zabbix che state utilizzando.<\/p>\n<p>E l'ultimo passaggio...<\/p>\n<h3>TimescaleDB. Migrazione delle tabelle della cronologia<\/h3>\n<p>\nHai bisogno di creare un hypertable. Per fare ci\u00f2, c'\u00e8 una funzione speciale \u2013 Crea hypertable. Qui il primo parametro indica la tabella che \u00e8 necessaria in questo DB (per la quale \u00e8 necessario creare l'ibrida).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 che devono essere utilizzate). 86 400 \u00e8 un giorno. <\/p>\n<p>Il parametro migrate_data: se lo imposti su true, trasferisce tutti i dati correnti nei chunk precedentemente creati.<\/p>\n<p>Ho personalmente utilizzato migrate_data \u2013 ci vuole un bel po' di tempo, a seconda delle dimensioni del tuo DB. Avevo pi\u00f9 di un terabyte \u2013 la creazione ha impiegato pi\u00f9 di un'ora. In alcuni casi, durante i test, ho eliminato i dati storici per il testo (history_text) e la stringa (history_str), per non trasferirli \u2013 in realt\u00e0 non mi interessavano.<\/p>\n<p>E l'ultimo aggiornamento che facciamo nella nostra db_extention: installiamo timescaledb, in modo che il DB e, in particolare, il nostro \u00abZabbix\u00bb possano capire che esiste db_extention. Lo attiva e utilizza correttamente la sintassi e le query al DB, avvalendosi gi\u00e0 delle \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 configurato su di esso \u00abPostgres\u00bb 10.8:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 fatto le configurazioni minime per utilizzare proprio questo database, a parte ci\u00f2 che user\u00e0 \u00abZabbix\u00bb. Su questa stessa macchina era installato il server \u00abZabbix\u00bb, PostgreSQL e gli agenti di carico.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/a6efa9ab9cd58f0061d04f13fe31018c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHo utilizzato 50 agenti attivi, che utilizzano LoadableModule, per generare rapidamente vari risultati. Sono stati loro a generare righe, numeri e cos\u00ec via. Ho riempito il DB con una grande quantit\u00e0 di dati. Inizialmente la configurazione conteneva 5 mila elementi di dati per ogni host e circa ogni elemento di dati conteneva un trigger \u2013 per avere una configurazione reale. A volte \u00e8 necessaria anche pi\u00f9 di un trigger.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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, il carico stesso lo regolavo non solo utilizzando 50 agenti (ne aggiungevo di pi\u00f9), ma anche con elementi di dati dinamici e abbassavo l'intervallo di aggiornamento a 4 secondi.<\/p>\n<h3>Test delle prestazioni. PostgreSQL: 36 mila NVP.<\/h3>\n<p>\nIl primo avvio, la prima configurazione l'ho avuta su un PostgreSQL 10 pulito su questa macchina (35 mila valori al secondo). In generale, come si vede sullo schermo, l'inserimento dei dati richiede frazioni di secondo \u2013 tutto \u00e8 buono e veloce, dischi SSD (200 gigabyte). L'unica cosa \u00e8 che 20 GB si riempiono piuttosto rapidamente.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/6803a64fedd26093b9117a036d2993ae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCi saranno in seguito molti di questi grafici. Questo \u00e8 il dashboard delle prestazioni standard del server \u00abZabbix\u00bb.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/081cc11c6bf42db3f8f16b6cc4e6ee0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl primo grafico \u2013 il numero di valori al secondo (blu, in alto a sinistra), 35 mila valori in questo caso. Questo (in alto al centro) \u00e8 il carico dei processi di raccolta, mentre questo (in alto a destra) \u00e8 il carico dei processi interni: history syncers e housekeeper, che qui (in basso al centro) \u00e8 stato in esecuzione per abbastanza tempo.<\/p>\n<p>Questo grafico (in basso al centro) mostra l'uso di ValueCache: quante hit di ValueCache ci sono per i trigger (diverse migliaia di valori al secondo). Un altro grafico importante \u00e8 il quarto (in basso a sinistra), che mostra l'uso di HistoryCache, di cui ho parlato, che funge da buffer prima dell'inserimento nel database.<\/p>\n<h3>Test di performance. PostgreSQL: 50 mila NVP<\/h3>\n<p>\nSuccessivamente ho aumentato il carico a 50 mila valori al secondo su questa stessa macchina. Durante il caricamento da parte di \"Housekeeper\", 10 mila valori venivano gi\u00e0 scritti in 2-3 secondi con calcolo. Questo, in effetti, \u00e8 mostrato nello screenshot successivo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/80824da986dbee2f8d5ebe0ead4fbcfd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\"Housekeeper\" inizia gi\u00e0 a interferire con il lavoro, ma nel complesso il carico dei trapper di history-syncer \u00e8 ancora al 60% (terzo grafico, in alto a destra). HistoryCache inizia gi\u00e0 a riempirsi attivamente durante l'operazione di \"Housekeeper\" (in basso a sinistra). Era di circa mezzo gigabyte e si stava riempiendo al 20%.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 performance. PostgreSQL: 80 mila NVP<\/h3>\n<p>\nHo poi aumentato a 80 mila valori al secondo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/13ae1589d6b9d35b4dda9c6c7d989cc2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nErano circa 400 mila elementi di dati, 280 mila trigger. L'inserimento, come puoi vedere, era gi\u00e0 abbastanza alto per il carico degli history-syncer (ce ne erano 30). Poi ho aumentato vari parametri: history-syncer, cache... Su questa macchina il carico degli history-syncer ha iniziato ad aumentare al massimo, praticamente \"saturato\" \u2013 di conseguenza, HistoryCache ha raggiunto un carico molto alto:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 del sistema (come viene utilizzata la CPU, la memoria RAM) e ho scoperto che l'utilizzo dei dischi era massimo \u2013 ho raggiunto la capacit\u00e0 massima di questo disco su questa macchina, su questa macchina virtuale. \"Postgres\" ha iniziato a scaricare i dati in modo abbastanza attivo a tale intensit\u00e0 e il disco non riusciva pi\u00f9 a scrivere, leggere...<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/53410b502a4574aac5d40f1a2a6d3f42.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL'ho anche \"ottimizzato\" \u2013 ho installato 60 history syncer e ho ottenuto prestazioni accettabili. Di fatto, non siamo pi\u00f9 \"saturati\", ma questo \u00e8 gi\u00e0, probabilmente, il limite di prestazione, dove \u00e8 necessario intraprendere qualche azione.<\/p>\n<h3>Test di performance. TimescaleDB: 80 mila NVP<\/h3>\n<p>\nLa mia principale sfida era utilizzare TimescaleDB. Ogni grafico mostra un calo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/b0064068895a34b93b5aa6771aba05cb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesti fallimenti rappresentano esattamente la migrazione dei dati. Dopo ci\u00f2, nel server Zabbix, il profilo di caricamento degli storici dei sincronizzatori, come vedete, \u00e8 cambiato drasticamente. Consente di inserire i dati quasi tre volte pi\u00f9 velocemente e di utilizzare meno HistoryCache; di conseguenza, i dati saranno forniti tempestivamente. Ancora una volta, 80.000 valori al secondo \u00e8 un tasso abbastanza alto (certo, non per Yandex). In generale, si tratta di un setup abbastanza grande, con un solo server.<\/p>\n<h3>Test di prestazioni di PostgreSQL: 120.000 NVP.<\/h3>\n<p>\nSuccessivamente, ho aumentato il valore del numero di elementi dati a mezzo milione e ho ottenuto un valore stimato di 125.000 al secondo:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/7d0cf2ef7c6691c1bbf4b90afd34e4bb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE ho ottenuto grafici come questi:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/9c09333a50e016921a8a5b70e00397a1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn linea di principio, questo \u00e8 un setup funzionante, pu\u00f2 operare per un tempo piuttosto lungo. Ma poich\u00e9 avevo un disco di soli 1,5 terabyte, l'ho esaurito in pochi giorni. La cosa pi\u00f9 importante \u00e8 che nel frattempo si stavano creando nuove partizioni su TimescaleDB, e questo per le prestazioni \u00e8 avvenuto completamente senza che se ne accorgesse, cosa che non si pu\u00f2 dire per MySQL.<\/p>\n<p>Di solito le partizioni vengono create di notte perch\u00e9 ci\u00f2 blocca completamente l\u2019inserimento e il lavoro con le tabelle, e pu\u00f2 portare a una degradazione del servizio. In questo caso non \u00e8 successo! L'obiettivo principale era verificare le capacit\u00e0 di TimescaleDB. \u00c8 emersa questa cifra: 120.000 valori al secondo.<\/p>\n<p>Ci sono anche esempi nella comunit\u00e0:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo\" src=\"\/wp-content\/uploads\/2020\/01\/66aa6b1d4c559d12082e4d91b6a1ca10.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUna persona ha anche attivato TimescaleDB e il caricamento per l\u2019utilizzo di io.weight \u00e8 diminuito sulla CPU; e l'uso degli elementi dei processi interni \u00e8 diminuito grazie all'attivazione di TimescaleDB. Inoltre, si tratta di dischi normali, cio\u00e8 una normale macchina virtuale su dischi convenzionali (non SSD)!<\/p>\n<p>Per alcuni piccoli setup che si scontrano con le prestazioni del disco, TimescaleDB, a mio parere, \u00e8 una soluzione molto buona. Permetter\u00e0 di continuare a lavorare fino a quando non si migrer\u00e0 su hardware pi\u00f9 veloce per il database.<\/p>\n<p>Vi invitiamo tutti ai nostri eventi: Conferenza \u2013 a Mosca, Summit \u2013 a Riga. Utilizzate i nostri canali: Telegram, forum, IRC. Se avete domande, venite al nostro 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 semplice da configurare e offre un tale incremento delle prestazioni, forse sarebbe utile utilizzarlo come migliore pratica per configurare \u00abZabbix\u00bb con \u00abPostgres\u00bb? Ci sono delle insidie e svantaggi in questa soluzione, o se ho deciso di fare \u00abZabbix\u00bb, posso tranquillamente prendere \u00abPostgres\u00bb, installare subito \u00abTimescale\u00bb e usarlo senza pensare a problemi?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 \u00abPostgres\u00bb direttamente con l'estensione TimescaleDB. Come ho gi\u00e0 detto, ci sono molte buone recensioni, nonostante questa \u00abfeature\u00bb sia sperimentale. Ma in realt\u00e0 i test dimostrano che \u00e8 un'ottima soluzione (con TimescaleDB) e credo che si sviluppi! Stiamo monitorando come si evolve questa estensione e apporteremo le modifiche necessarie.<\/p>\n<p>Anche durante lo sviluppo ci siamo basati su una delle loro note \u00abfeature\u00bb: l\u00ec si poteva lavorare un po' diversamente con i chunk. Ma poi l'hanno rimossa nella release successiva, e abbiamo dovuto smettere di fare affidamento su quel codice. Consiglierei di utilizzare questa soluzione in molte configurazioni. Se usate MySQL\u2026 Per configurazioni medio-piccole, qualsiasi soluzione funziona abbastanza bene.<\/p>\n<p><b>A:<\/b> \u2013 Negli ultimi grafici, forniti dalla community, c'era un grafico con \u00abHousekeeper\u00bb:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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 \u00abHousekeeper\u00bb nel caso di TimescaleDB?<\/p>\n<p><b>AG:<\/b> \u2013 Al momento non posso dirlo con certezza \u2013 guarder\u00f2 il codice e fornir\u00f2 ulteriori dettagli. Utilizza le query di TimescaleDB non per eliminare i chunk, ma in qualche modo aggrega. Finora non sono pronto a rispondere a questa domanda tecnica. Su questo aspetto chiariremo oggi o domani.<\/p>\n<p><b>A:<\/b> \u2013 Ho una domanda simile \u2013 sulla performance delle operazioni di eliminazione in \u00abTimescale\u00bb.<br \/>\nA (risposta dal pubblico): \u2013 Quando elimini dati da una tabella, se lo fai tramite delete, devi attraversare la tabella \u2013 rimuovere, pulire, contrassegnare tutto per il futuro vacuum. In \u00abTimescale\u00bb, poich\u00e9 hai dei chunk, puoi eliminarli. In sostanza, stai semplicemente dicendo al file, che si trova nei big data: \u00abElimina!\u00bb<\/p>\n<p>\u00abTimeScale\u00bb capisce semplicemente che quel chunk non esiste pi\u00f9. E poich\u00e9 si integra con il pianificatore delle richieste, cattura le tue condizioni nel select o in altre operazioni e comprende immediatamente che quel chunk non \u00e8 pi\u00f9 disponibile \u2013 \u00abNon ci andr\u00f2 pi\u00f9!\u00bb (dati assenti). Ecco tutto! Quindi la scansione della tabella viene sostituita con la cancellazione di un file binario, quindi \u00e8 veloce.<\/p>\n<p><b>A:<\/b> \u2013 Abbiamo gi\u00e0 toccato il tema del non SQL. Da quanto ho capito, \u00abZabbix\u00bb non ha realmente bisogno di modificare i dati, e tutto questo \u00e8 una sorta di log. \u00c8 possibile utilizzare database specializzati che non possono modificare i propri dati, ma che al contempo salvano, accumulano e restituiscono molto pi\u00f9 rapidamente \u2013 Clickhouse, ad esempio, qualcosa di simile a Kafka?.. Kafka \u00e8 anch'esso un log! Possono essere integrati in qualche modo?<\/p>\n<p><b>AG:<\/b> \u2013 \u00c8 possibile fare l'esportazione. Abbiamo una certa \"feature\" dalla versione 3.4: puoi scrivere in file tutti i file storici, eventi e tutto il resto; e successivamente, tramite qualche elaboratore, inviarli a qualsiasi altro DB. In realt\u00e0, molti ristrutturano e scrivono direttamente nel DB. I history-sinkers in tempo reale scrivono tutto questo in file, ruotano questi file e cos\u00ec via, e puoi trasferirli in \u00abClickhouse\u00bb. Non posso dire nulla sui piani, ma forse il supporto futuro per le soluzioni NoSQL (come \u00abClickhouse\u00bb) continuer\u00e0.<\/p>\n<p><b>A:<\/b> \u2013 Quindi, in effetti, \u00e8 possibile eliminare completamente Postgres?<\/p>\n<p><b>AG:<\/b> \u2013 Certo, la parte pi\u00f9 complessa di \u00abZabbix\u00bb sono le tabelle storiche, che creano pi\u00f9 problemi, e gli eventi. In questo caso, se non intendi conservare a lungo gli eventi e conserverai la storia con i trend in un altro sistema di archiviazione veloce, in generale non ci saranno problemi, suppongo.<\/p>\n<p><b>A:<\/b> \u2013 Puoi valutare quanto sar\u00e0 pi\u00f9 veloce tutto se passiamo a \u00abClickhouse\u00bb, ad esempio?<\/p>\n<p><b>AG:<\/b> \u2013 Non ho fatto test. Penso che almeno le stesse cifre possano essere raggiunte piuttosto facilmente, considerando che \u00abClickhouse\u00bb ha la sua interfaccia, ma non posso dire con certezza. \u00c8 meglio testare. Tutto dipende dalla configurazione: quanti host hai e cos\u00ec via. L'inserimento \u00e8 una cosa, ma bisogna anche recuperare questi dati \u2013 con Grafana o altro.<\/p>\n<p><b>A:<\/b> \u2013 Quindi stiamo parlando di una lotta equilibrata, e non di un grande vantaggio di questi DB veloci?<\/p>\n<p><b>AG:<\/b> \u2013 Penso che quando integreremo, avremo test pi\u00f9 accurati.<\/p>\n<p><b>A:<\/b> \u2013 E dove \u00e8 finito il caro vecchio RRD? Cosa ha portato al passaggio ai database SQL? Inizialmente tutte le metriche venivano raccolte su RRD.<\/p>\n<p><b>AG:<\/b> \u2013 In \u00abZabbix\u00bb RRD, forse, era presente in una versione molto antica. I database SQL sono sempre stati presenti \u2013 \u00e8 un approccio classico. L'approccio classico \u00e8 MySQL, PostgreSQL (esistono da molto tempo). Abbiamo un'interfaccia comune per i database SQL e non abbiamo praticamente mai utilizzato RRD.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): alte 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=\"Guarda il 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 rimanere con noi. Ti piacciono i nostri articoli? Vuoi vedere pi\u00f9 contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci a qualcuno. <noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/cloudvps\/nl\">VPS cloud per sviluppatori a partire da $4.99.<\/a><\/noindex>, <b>unica alternativa ai server entry-level, concepita da noi per te:<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/347386\/\">Tutta la verit\u00e0 sui VPS (KVM) E5-2697 v3 (6 Core) 10GB DDR4 480GB SSD 1Gbps a partire da $19 o come dividere correttamente un server?<\/a><\/noindex> (sono 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> Leggi di <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">Come costruire un'infrastruttura di livello enterprise utilizzando server Dell R730xd E5-2650 v4 del valore di 9000 euro a pochi spiccioli?<\/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.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/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.1.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++, Andrey Gushchin (Zabbix): alte prestazioni e partizionamento nativo | ProHoster","description":"Esamineremo il funzionamento di Zabbix con il database TimescaleDB come backend. Mostreremo come avviare 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}]}}