{"id":56075,"date":"2020-02-04T00:00:00","date_gmt":"2020-02-03T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/osnovy-monitoringa-postgresql-aleksej-lesovskij"},"modified":"2020-02-18T14:04:16","modified_gmt":"2020-02-18T11:04:16","slug":"osnovy-monitoringa-postgresql-aleksej-lesovskij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/osnovy-monitoringa-postgresql-aleksej-lesovskij","title":{"rendered":"Fondamenti del monitoraggio di PostgreSQL. Alexey Lesovskiy","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439 \u0438\u0437 Data Egret "\u041e\u0441\u043d\u043e\u0432\u044b \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 PostgreSQL"<\/strong><\/p>\n

<\/p>\n

\u0412 \u044d\u0442\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u0442 \u043e \u043a\u043b\u044e\u0447\u0435\u0432\u044b\u0445 \u043c\u043e\u043c\u0435\u043d\u0442\u0430\u0445 \u043f\u043e\u0441\u0442\u0433\u0440\u0435\u0441\u043e\u0432\u043e\u0439 \u0441\u0442\u0430\u0442\u0438\u0441\u0442\u0438\u043a\u0438, \u0447\u0442\u043e \u043e\u043d\u0438 \u043e\u0437\u043d\u0430\u0447\u0430\u044e\u0442, \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u043e\u043d\u0438 \u0434\u043e\u043b\u0436\u043d\u044b \u043f\u0440\u0438\u0441\u0443\u0442\u0441\u0442\u0432\u043e\u0432\u0430\u0442\u044c \u0432 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435; \u043e \u0442\u043e\u043c, \u043a\u0430\u043a\u0438\u0435 \u0433\u0440\u0430\u0444\u0438\u043a\u0438 \u0434\u043e\u043b\u0436\u043d\u044b \u0431\u044b\u0442\u044c \u0432 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435, \u043a\u0430\u043a \u0438\u0445 \u0434\u043e\u0431\u0430\u0432\u0438\u0442\u044c \u0438 \u043a\u0430\u043a \u0438\u043d\u0442\u0435\u0440\u043f\u0440\u0435\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c. \u0414\u043e\u043a\u043b\u0430\u0434 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u043b\u0435\u0437\u0435\u043d \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u0430\u043c \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445, \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u043c \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u0430\u043c \u0438 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430\u043c, \u043a\u043e\u0442\u043e\u0440\u044b\u043c \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u0435\u043d \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u043d\u0433 Postgres’\u0430.<\/p>\n

\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Mi chiamo Alexey Lesovskiy e rappresento l'azienda Data Egret. <\/p>\n

<\/p>\n

Un po' di parole su di me. Ho iniziato tanto tempo fa come amministratore di sistema. <\/p>\n

<\/p>\n

Ho gestito vari sistemi Linux, occupandomi di diverse attivit\u00e0 legate a Linux, come virtualizzazione, monitoraggio, lavoro con proxy, ecc. Ma a un certo punto ho iniziato a concentrarmi di pi\u00f9 sui database, in particolare su PostgreSQL, che mi \u00e8 sempre piaciuto. Cos\u00ec, col tempo, sono diventato un DBA di PostgreSQL.<\/p>\n

<\/p>\n

Nel corso della mia carriera, sono sempre stato interessato a temi come la statistica, il monitoraggio e la raccolta di telemetria. Quando ero amministratore di sistema, ho lavorato intensamente con Zabbix e ho scritto un piccolo insieme di script come zabbix-extensions<\/a><\/noindex>. Era piuttosto popolare nel suo periodo. Con esso, era possibile monitorare molte cose importanti, non solo Linux, ma anche diversi altri componenti.<\/p>\n

<\/p>\n

Attualmente mi occupo di PostgreSQL. Sto sviluppando un altro strumento che permette di lavorare con le statistiche di PostgreSQL. Si chiama pgCenter<\/a><\/noindex> (articolo su Habr\u00e9 \u2014 Statistiche PostgreSQL senza stress e complicazioni<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Una breve introduzione. Quali situazioni possono presentarsi per i nostri clienti? Si verifica un malfunzionamento relativo al database. E quando il database \u00e8 stato ripristinato, il capo del dipartimento o il project manager dice: \u00abAmici, dovremmo monitorare il database, perch\u00e9 \u00e8 successo qualcosa di brutto e dobbiamo evitare che accada di nuovo in futuro\u00bb. Qui inizia un interessante processo di scelta del sistema di monitoraggio o di adattamento del sistema di monitoraggio esistente per monitorare il proprio database \u2013 PostgreSQL, MySQL o altri. E i colleghi iniziano a suggerire: \u00abHo sentito dire che esiste un certo database. Utilizziamolo\u00bb. I colleghi iniziano a discutere tra loro. Alla fine, scegliamo un database, ma il monitoraggio di PostgreSQL \u00e8 rappresentato in modo piuttosto scarso e dobbiamo sempre fare qualche aggiustamento. Prendiamo alcune repository da GitHub, le cloniamo, adattiamo gli script e facciamo delle impostazioni. Alla fine, questo si traduce in un certo lavoro manuale. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

In questo documento cercher\u00f2 di fornirvi alcune informazioni su come scegliere il monitoraggio non solo per PostgreSQL, ma anche per i database in generale. Voglio darvi le conoscenze necessarie per affinare il vostro monitoraggio, in modo da ottenere un reale beneficio, consentendovi di monitorare il vostro database in maniera utile e di avvisarvi in tempo di eventuali situazioni critiche che potrebbero presentarsi. <\/p>\n

<\/p>\n

Le idee che presenter\u00f2 in questo documento possono essere adattate direttamente a qualsiasi database, sia esso un DBMS tradizionale o un noSQL. Pertanto, ci sar\u00e0 molto pi\u00f9 di PostgreSQL, con molte ricette su come implementare queste idee in PostgreSQL. Vi fornir\u00f2 esempi di query, esempi di entit\u00e0 che esistono in PostgreSQL per il monitoraggio. E se il vostro DBMS ha elementi simili che possono essere integrati nel monitoraggio, anche voi potrete adattarli e aggiungerli.<\/p>\n

<\/p>\n

\"FondamentiNel documento non tratter\u00f2
\ncome raccogliere e memorizzare le metriche. Non parler\u00f2 della post-elaborazione dei dati e della loro presentazione all'utente. E non dir\u00f2 nulla sugli avvisi.
\nDurante la narrazione, mostrer\u00f2 vari screenshot di monitoraggi esistenti e li criticher\u00f2. Tuttavia, cercher\u00f2 di non nominare i marchi, in modo da non promuovere o denigrare quei prodotti. Pertanto, tutte le somiglianze sono casuali e rimangono nella vostra immaginazione.
\n\"Fondamenti
\nIniziamo a capire cosa sia il monitoraggio. Il monitoraggio \u00e8 una cosa molto importante da avere. Tutti lo comprendono. Tuttavia, allo stesso tempo, il monitoraggio non \u00e8 un prodotto di business e non influisce direttamente sul profitto dell'azienda, perci\u00f2 viene sempre considerato come una priorit\u00e0 secondaria. Se abbiamo tempo, ci dedichiamo al monitoraggio, se non abbiamo tempo, va bene, lo mettiamo in backlog e un giorno torneremo su queste attivit\u00e0. <\/p>\n

<\/p>\n

Pertanto, dalla nostra esperienza, quando ci rechiamo dai clienti, il monitoraggio \u00e8 spesso carente e non presenta elementi interessanti che ci aiuterebbero a lavorare meglio con il database. Per questo motivo, il monitoraggio deve sempre essere perfezionato. <\/p>\n

<\/p>\n

I database sono sistemi complessi che richiedono monitoraggio, poich\u00e9 rappresentano un deposito di informazioni. Queste informazioni sono essenziali per un'azienda e non devono essere mai perse. Al tempo stesso, i database sono pezzi di software molto sofisticati, composti da numerosi componenti, molti dei quali necessitano di essere monitorati. <\/p>\n

<\/p>\n

\"FondamentiSe parliamo specificamente di PostgreSQL, possiamo rappresentarlo come uno schema composto da tanti componenti che interagiscono tra loro. Allo stesso tempo, in PostgreSQL esiste una sottosistema chiamata Stats Collector, che consente di raccogliere statistiche sul funzionamento di questi sottosistemi e fornisce un'interfaccia all'amministratore o all'utente per visualizzare queste statistiche. <\/p>\n

<\/p>\n

Queste statistiche vengono presentate tramite un insieme di funzioni e viste (view), che possono essere considerate come tabelle. Pertanto, utilizzando un normale client psql, puoi collegarti al database, eseguire select su queste funzioni e viste e ottenere numeri specifici riguardanti il funzionamento dei sottosistemi di PostgreSQL. <\/p>\n

<\/p>\n

Puoi aggiungere questi numeri al tuo sistema di monitoraggio preferito, tracciare grafici, aggiungere funzioni e ottenere analisi a lungo termine. <\/p>\n

<\/p>\n

Tuttavia, in questa relazione non tratter\u00f2 tutte queste funzioni, poich\u00e9 ci\u00f2 potrebbe richiedere un'intera giornata. Mi concentrer\u00f2 su due, tre o quattro cose specifiche e spiegher\u00f2 come possono migliorare il monitoraggio.
\n\"Fondamenti
\nE parlando del monitoraggio del database, cosa bisogna monitorare? Innanzitutto, \u00e8 fondamentale monitorare la disponibilit\u00e0, poich\u00e9 il database \u00e8 un servizio che fornisce accesso ai dati ai clienti, e dobbiamo assicurarti che la disponibilit\u00e0 venga mantenuta, insieme ad alcune sue caratteristiche qualitative e quantitative. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Inoltre, \u00e8 importante monitorare i clienti che si connettono al nostro database, poich\u00e9 possono essere sia clienti normali che clienti dannosi in grado di compromettere il database. Anche la loro attivit\u00e0 deve essere monitorata e tracciata.<\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Quando i clienti si connettono al database, \u00e8 evidente che iniziano a lavorare con i nostri dati. Pertanto, dobbiamo monitorare anche come i clienti interagiscono con i dati: quali tabelle utilizzano e, in misura minore, quali indici. In altre parole, dobbiamo valutare il carico di lavoro (workload) generato dai nostri clienti.<\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Ma anche il workload \u00e8 composto, ovviamente, da richieste. Le applicazioni si connettono al database e accedono ai dati tramite richieste, quindi \u00e8 importante valutare quali richieste abbiamo nel database, monitorarne l'adeguatezza, assicurandoci che non siano scritte in modo errato, e che alcune opzioni necessitino di essere riscritte per garantire una maggiore velocit\u00e0 e prestazioni migliori. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

E poich\u00e9 parliamo di database, un database \u00e8 sempre costituito da processi in background. I processi in background consentono di mantenere le prestazioni del database a un buon livello, quindi per funzionare richiedono una certa quantit\u00e0 di risorse. Allo stesso tempo, possono sovrapporsi alle risorse delle richieste dei clienti, quindi un'operazione troppo intensiva dei processi in background pu\u00f2 influenzare direttamente le prestazioni delle richieste dei clienti. Pertanto, \u00e8 necessario monitorarli e verificare che non ci siano squilibri riguardo ai processi in background. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

E tutto ci\u00f2 in termini di monitoraggio del database rimane nelle metriche di sistema. Ma considerando che gran parte della nostra infrastruttura si sposta nel cloud, le metriche di sistema di un host individuale passano sempre in secondo piano. Tuttavia, nei database rimangono comunque rilevanti, e il monitoraggio delle metriche di sistema \u00e8 certamente necessario. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Con le metriche di sistema, in generale, tutto \u00e8 abbastanza a posto; tutti i moderni sistemi di monitoraggio gi\u00e0 supportano queste metriche, ma ci sono comunque alcune componenti che mancano e che devono essere aggiunte. Ne parler\u00f2 anche, ci saranno alcuni slide su di esse. <\/p>\n

<\/p>\n

\"Fondamenti
\nIl primo punto del piano \u00e8 la disponibilit\u00e0. Cosa significa disponibilit\u00e0? Nel mio concetto, la disponibilit\u00e0 \u00e8 la capacit\u00e0 di un database di gestire le connessioni, ovvero il database \u00e8 attivo e accetta connessioni dai clienti come un servizio. Questa disponibilit\u00e0 pu\u00f2 essere valutata tramite alcune caratteristiche. \u00c8 molto utile visualizzare queste caratteristiche nei dashboard. <\/p>\n

<\/p>\n

\"Fondamenti
\nTutti sanno cosa sono i dashboard. \u00c8 quando dai un'occhiata a uno schermo su cui \u00e8 sintetizzata l'informazione necessaria. E puoi subito capire se c'\u00e8 un problema nel database o meno.
\nPertanto, la disponibilit\u00e0 del database e altre caratteristiche chiave devono sempre essere visualizzate nei dashboard, affinch\u00e9 queste informazioni siano a portata di mano, sempre disponibili per te. Ulteriori dettagli, che aiutano nelle indagini sugli incidenti e sulle situazioni di emergenza, devono essere inseriti in dashboard secondari o nascosti in link drilldown che portano a sistemi di monitoraggio esterni. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Esempio di un noto sistema di monitoraggio. Si tratta di un sistema di monitoraggio davvero interessante. Raccoglie un'enorme quantit\u00e0 di dati, ma dal mio punto di vista, ha una concezione strana dei cruscotti. C'\u00e8 un link per \"creare un cruscotto\". Ma quando crei un cruscotto, stai creando un elenco, composto da due colonne, un elenco di grafici. E quando devi controllare qualcosa, inizi a cliccare con il mouse, a scorrere, a cercare il grafico desiderato. E questo richiede tempo, cio\u00e8, non ci sono cruscotti veri e propri. Ci sono solo elenchi di grafici.<\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Cosa bisogna aggiungere a questi cruscotti? Puoi iniziare con una caratteristica come il tempo di risposta. In PostgreSQL c'\u00e8 la vista pg_stat_statements. Di default \u00e8 disabilitata, ma \u00e8 una delle viste sistemiche pi\u00f9 importanti che deve sempre essere attivata e utilizzata. Contiene informazioni su tutte le query eseguite che sono state effettuate nel database. <\/p>\n

<\/p>\n

\u0421\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e, \u043c\u044b \u043c\u043e\u0436\u0435\u043c \u043e\u0442\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u0441\u044f \u043e\u0442 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e \u043c\u043e\u0436\u043d\u043e \u0432\u0437\u044f\u0442\u044c \u0441\u0443\u043c\u043c\u0430\u0440\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u0432\u0441\u0435\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u0438 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c \u043d\u0430 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0432\u044b\u0448\u0435\u043f\u0440\u0438\u0432\u0435\u0434\u0435\u043d\u043d\u044b\u0445 \u043f\u043e\u043b\u0435\u0439. \u041d\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u0430\u044f \u0441\u0440\u0435\u0434\u043d\u044f\u044f \u0442\u0435\u043c\u043f\u0435\u0440\u0430\u0442\u0443\u0440\u0430 \u043f\u043e \u0431\u043e\u043b\u044c\u043d\u0438\u0446\u0435. \u041c\u044b \u043c\u043e\u0436\u0435\u043c \u043e\u0442\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u0441\u044f \u043e\u0442 \u0434\u0440\u0443\u0433\u0438\u0445 \u043f\u043e\u043b\u0435\u0439 \u2013 \u043c\u0438\u043d\u0438\u043c\u0430\u043b\u044c\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432, \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e\u0435 \u0438 \u043c\u0435\u0434\u0438\u0430\u043d\u043d\u043e\u0435. \u0418 \u0434\u0430\u0436\u0435 \u043c\u043e\u0436\u0435\u043c \u0441\u0442\u0440\u043e\u0438\u0442\u044c \u043f\u0435\u0440\u0446\u0435\u043d\u0442\u0438\u043b\u0438, \u0432 PostgreSQL \u0435\u0441\u0442\u044c \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0435 \u0444\u0443\u043d\u043a\u0446\u0438\u0438 \u0434\u043b\u044f \u044d\u0442\u043e\u0433\u043e. \u0418 \u043c\u044b \u043c\u043e\u0436\u0435\u043c \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043a\u0430\u043a\u0438\u0435-\u0442\u043e \u0446\u0438\u0444\u0440\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440\u0438\u0437\u0443\u044e\u0442 \u0432\u0440\u0435\u043c\u044f \u043e\u0442\u043a\u043b\u0438\u043a\u0430 \u043d\u0430\u0448\u0435\u0439 \u0431\u0430\u0437\u044b \u043f\u043e \u0443\u0436\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u043d\u044b\u043c \u0437\u0430\u043f\u0440\u043e\u0441\u0430\u043c, \u0442. \u0435. \u043c\u044b \u043d\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u043c \u0444\u0435\u0439\u043a\u043e\u0432\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441 ‘select 1’\u00a0\u0438 \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0440\u0435\u043c\u044f \u043e\u0442\u043a\u043b\u0438\u043a\u0430, \u0430 \u043c\u044b \u0430\u043d\u0430\u043b\u0438\u0437\u0438\u0440\u0443\u0435\u043c \u0432\u0440\u0435\u043c\u044f \u043e\u0442\u0432\u0435\u0442\u043e\u0432 \u043f\u043e \u0443\u0436\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u043d\u044b\u043c \u0437\u0430\u043f\u0440\u043e\u0441\u0430\u043c \u0438 \u0440\u0438\u0441\u0443\u0435\u043c \u043b\u0438\u0431\u043e \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u043e\u0439 \u0446\u0438\u0444\u0440\u043e\u0439, \u043b\u0438\u0431\u043e \u0441\u0442\u0440\u043e\u0438\u043c \u043f\u043e \u043d\u0435\u0439 \u0433\u0440\u0430\u0444\u0438\u043a. <\/p>\n

<\/p>\n

\u00c8 altrettanto importante tenere traccia del numero di errori attualmente generati dal sistema. Per fare ci\u00f2, possiamo utilizzare la vista pg_stat_database. Ci concentriamo sul campo xact_rollback. Questo campo non solo mostra il numero di rollback che si verificano nel database, ma tiene anche conto del numero di errori. In altre parole, possiamo visualizzare questo dato nel nostro dashboard e monitorare quanti errori abbiamo attualmente. Se ci sono molti errori, \u00e8 un buon motivo per dare un'occhiata ai log e vedere quali sono questi errori e perch\u00e9 si verificano, e poi indagare e risolverli.<\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

\u00c8 possibile aggiungere un elemento come il Tachimetro. Questo misura il numero di transazioni al secondo e il numero di richieste al secondo. In altre parole, puoi utilizzare questi numeri come indicatore delle prestazioni attuali del tuo database e osservare se ci sono picchi nelle richieste, picchi nelle transazioni o, al contrario, se il database \u00e8 sottoutilizzato a causa di qualche malfunzionamento nel backend. \u00c8 importante monitorare sempre questo valore e tenere a mente che per il nostro progetto, questa \u00e8 considerata una prestazione normale, mentre valori superiori o inferiori sono problematici e non chiari, il che implica la necessit\u00e0 di indagare il motivo di tali numeri.<\/p>\n

<\/p>\n

Per valutare il numero di transazioni, possiamo nuovamente fare riferimento alla vista pg_stat_database. Possiamo sommare il numero di commit e il numero di rollback per ottenere il numero di transazioni al secondo. <\/p>\n

<\/p>\n

Tutti capiscono che in una transazione possono rientrare pi\u00f9 richieste, vero? Quindi TPS e QPS sono leggermente diversi. <\/p>\n

<\/p>\n

Il numero di richieste al secondo pu\u00f2 essere ottenuto tramite pg_stat_statements e semplicemente calcolando la somma di tutte le richieste eseguite. \u00c8 chiaro che confrontiamo il valore attuale con quello precedente, sottraiamo e otteniamo la variazione, arrivando cos\u00ec al numero.<\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

\u00c8 possibile aggiungere ulteriori metriche a piacere, che aiutano anche a valutare la disponibilit\u00e0 del nostro database e a monitorare eventuali downtime. <\/p>\n

<\/p>\n

Una di queste metriche \u00e8 l'uptime. Ma l'uptime in PostgreSQL \u00e8 una questione un po' complicata. Ecco perch\u00e9. Quando PostgreSQL viene avviato, inizia a registrare l'uptime. Ma se in un certo momento, ad esempio, di notte viene eseguita un'operazione e l'OOM-killer termina forzatamente un processo figlio di PostgreSQL, in questo caso PostgreSQL chiude tutte le connessioni dei client, svuota la zona di memoria shardata e inizia il ripristino dall'ultimo checkpoint. E mentre dura questo ripristino dal checkpoint, il database non accetta connessioni, il che significa che questa situazione pu\u00f2 essere considerata un downtime. Tuttavia, il contatore dell'uptime non si azzera, poich\u00e9 tiene conto del tempo di avvio del postmaster fin dal primo momento. Pertanto, situazioni di questo tipo possono passare inosservate.<\/p>\n

<\/p>\n

\u00c8 importante monitorare il numero di worker del vacuum. Tutti sanno cos'\u00e8 l'autovacuum in PostgreSQL? \u00c8 un sistema secondario interessante in PostgreSQL. Sono stati scritti molti articoli su di essa, con molte presentazioni fatte. Ci sono stata molte discussioni sul vacuum e su come dovrebbe funzionare. Molti lo considerano un male necessario. Ma \u00e8 cos\u00ec. \u00c8 una sorta di equivalente di un garbage collector, che pulisce le versioni obsolete delle righe che non sono pi\u00f9 necessarie per nessuna delle transazioni e liberano spazio nelle tabelle e negli indici per nuove righe. <\/p>\n

<\/p>\n

Perch\u00e9 \u00e8 necessario monitorarlo? Perch\u00e9 il vacuum a volte pu\u00f2 causare problemi seri. Consuma molte risorse, e le richieste dei clienti iniziano a soffrirne. <\/p>\n

<\/p>\n

Bisogna monitorarlo tramite la vista pg_stat_activity, di cui parler\u00f2 nel prossimo capitolo. Questa vista mostra l'attivit\u00e0 corrente nel database. Attraverso quest'attivit\u00e0 possiamo tracciare il numero di vacuums che stanno lavorando in questo momento. Possiamo tenere traccia dei vacuum e vedere che, se superiamo il limite, \u00e8 un motivo per dare un'occhiata alle impostazioni di PostgreSQL e ottimizzare il funzionamento del vacuum. <\/p>\n

<\/p>\n

Un'altra caratteristica di PostgreSQL \u00e8 che soffre molto per le transazioni lunghe. In particolare, per le transazioni che rimangono in attesa senza eseguire alcuna operazione. Queste vengono chiamate stat idle-in-transaction. Una transazione di questo tipo trattiene i lock e interferisce con il funzionamento del vacuum. Di conseguenza, le tabelle crescono e aumentano di dimensione. Le query che lavorano su queste tabelle iniziano a rallentare perch\u00e9 bisogna scavare tutte le vecchie versioni delle righe dalla memoria al disco e viceversa.<\/strong> Pertanto, \u00e8 importante monitorare il tempo e la durata delle transazioni pi\u00f9 lunghe e delle query pi\u00f9 lunghe del vacuum. Se osserviamo processi che stanno funzionando da molto tempo, gi\u00e0 oltre 10-20-30 minuti per carichi OLTP, \u00e8 necessario prestare attenzione e forzarne la chiusura, oppure ottimizzare l'applicazione affinch\u00e9 non vengano attivate e non rimangano in attesa per cos\u00ec tanto tempo.<\/strong> Per i carichi analitici, 10-20-30 minuti sono normali; ci possono essere anche tempi pi\u00f9 lunghi. <\/p>\n

<\/p>\n

\"Fondamenti
\nPassiamo ora a una situazione con i clienti connessi. Una volta creato il dashboard e visualizzate le metriche chiave di disponibilit\u00e0, possiamo anche aggiungere ulteriori informazioni sui clienti connessi. <\/p>\n

<\/p>\n

Le informazioni sui clienti connessi sono importanti, perch\u00e9, dal punto di vista di PostgreSQL, i clienti possono essere diversi. Ci sono clienti buoni e clienti cattivi. <\/p>\n

<\/p>\n

Un esempio semplice. Con cliente intendo un'applicazione. L'applicazione si \u00e8 connessa al database e inizia subito a inviare le sue richieste; il database le elabora e esegue, restituendo i risultati al cliente. Questi sono clienti buoni e corretti. <\/p>\n

<\/p>\n

Ci sono situazioni in cui il cliente si \u00e8 connesso, mantiene la connessione, ma nel frattempo non fa nulla. Si trova in uno stato di inattivit\u00e0. <\/p>\n

<\/p>\n

Ma ci sono clienti problematici. Ad esempio, un cliente si connette, apre una transazione, fa qualcosa nel database e poi passa al codice, magari per accedere a una fonte esterna o per elaborare i dati ricevuti. Tuttavia, non chiude la transazione. Cos\u00ec, la transazione rimane aperta nel database, bloccando la riga. Questa \u00e8 una situazione negativa. Se l'applicazione, per qualche motivo, si interrompe a causa di un'eccezione, la transazione potrebbe rimanere aperta per molto tempo. Questo influisce direttamente sulle prestazioni di PostgreSQL, rallentando il suo funzionamento. \u00c8 quindi fondamentale monitorare questi clienti e terminare forzatamente la loro sessione quando necessario. \u00c8 essenziale ottimizzare la propria applicazione per evitare tali situazioni. <\/p>\n

<\/p>\n

Altri cattivi clienti sono quelli in attesa. Ma diventano cattivi a causa delle circostanze. Ad esempio, una semplice transazione in attesa: pu\u00f2 aprire una transazione, prendere blocchi su alcune righe e poi cadere da qualche parte nel codice, lasciando una transazione appesa. Arriver\u00e0 un altro cliente, richieder\u00e0 gli stessi dati, ma si imbatter\u00e0 in un blocco perch\u00e9 quella transazione appesa ha gi\u00e0 bloccato alcune righe necessarie. E la seconda transazione rimarr\u00e0 in attesa che la prima si concluda o venga forzatamente chiusa dall'amministratore. Cos\u00ec le transazioni in attesa possono accumularsi e riempire il limite di connessioni al database. Quando il limite \u00e8 superato, l'applicazione non pu\u00f2 pi\u00f9 lavorare con il database. Questa \u00e8 una situazione di emergenza per il progetto. Pertanto, \u00e8 necessario monitorare i cattivi clienti e reagire tempestivamente. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Un altro esempio di monitoraggio. E qui c'\u00e8 gi\u00e0 un bel dashboard. Ci sono informazioni sulle connessioni in alto. Connessioni DB \u2013 8 unit\u00e0. Ecco tutto. Non abbiamo informazioni sui clienti attivi, n\u00e9 su quelli che sono semplicemente inattivi, senza fare nulla. Non ci sono informazioni sulle transazioni in sospeso e sulle connessioni in attesa, quindi \u00e8 un dato che mostra solo il numero di connessioni e nulla pi\u00f9. Poi indovinate voi.
\n\"Fondamenti
\nPer aggiungere queste informazioni al monitoraggio, \u00e8 necessario fare riferimento alla vista pg_stat_activity. Se trascorri molto tempo in PostgreSQL, questa \u00e8 una vista molto utile che dovrebbe diventare la tua alleata, poich\u00e9 mostra l'attivit\u00e0 attuale in PostgreSQL, ossia cosa sta succedendo. Ogni processo ha una propria riga che visualizza informazioni su di esso: da quale host \u00e8 stata effettuata la connessione, quale utente ha effettuato l'accesso, con quale nome, quando \u00e8 stata avviata la transazione, quale query sta attualmente eseguendo, e quale query \u00e8 stata eseguita per ultima. Di conseguenza, possiamo valutare lo stato del client in base al campo stat. Possiamo, in un certo senso, raggruppare in base a questo campo e ottenere le statistiche attualmente presenti nel database e il numero di connessioni associate a queste statistiche. I numeri ottenuti possono quindi essere inviati al nostro monitoraggio e utilizzati per generare grafici.
\n\u00c8 anche importante valutare la durata delle transazioni. Ho gi\u00e0 accennato all'importanza di considerare la durata delle interruzioni, ma lo stesso vale per le transazioni. Ci sono i campi xact_start e query_start. Questi, per cos\u00ec dire, mostrano il momento di inizio della transazione e il momento di inizio della query. Usando la funzione now(), che mostra il timestamp corrente, sottraiamo il timestamp della transazione e della query. Cos\u00ec otteniamo la durata della transazione e la durata della query. <\/p>\n

<\/p>\n

Se vediamo transazioni lunghe, dovremmo gi\u00e0 completarle. Per carichi OLTP, le transazioni lunghe sono quelle che superano 1-2-3 minuti.<\/strong>. Per carichi OLAP, le transazioni lunghe sono normali, ma se superano le due ore, questo \u00e8 anche un segnale che da qualche parte abbiamo uno sbilanciamento.<\/strong> <\/p>\n

<\/p>\n

\"Fondamenti
\nQuando i clienti si connettono al database, iniziano a lavorare con i nostri dati. Accedono alle tabelle e agli indici per ottenere dati dalla tabella. \u00c8 importante valutare come i clienti interagiscono con questi dati.<\/p>\n

<\/p>\n

Questo \u00e8 necessario per valutare il nostro carico di lavoro e comprendere quali tabelle siano le pi\u00f9 \"calde\". Ad esempio, questo \u00e8 utile quando vogliamo posizionare le tabelle \"calde\" su un'archiviazione SSD veloce. D'altra parte, le tabelle archiviate che non utilizziamo da tempo possono essere spostate in un'archiviazione \"fredda\", su dischi SATA, e possono rimanere l\u00ec, con accesso solo quando necessario. <\/p>\n

<\/p>\n

\u00c8 anche utile per rilevare anomalie dopo vari rilasci e deployment. Ad esempio, un progetto potrebbe aver lanciato una nuova funzionalit\u00e0. Se abbiamo aggiunto nuove funzionalit\u00e0 per lavorare con il database e costruiamo grafici sull'uso delle tabelle, possiamo facilmente individuare queste anomalie grazie ai grafici. Ad esempio, picchi di update o picchi di delete saranno chiaramente visibili.<\/p>\n

<\/p>\n

\u00c8 possibile anche rilevare anomali nella statistica \"distorta\". Cosa significa? PostgreSQL ha un pianificatore di query molto potente e ben progettato. Gli sviluppatori dedicano molto tempo al suo sviluppo. Come funziona? Per creare buoni piani, PostgreSQL raccoglie periodicamente statistiche sulla distribuzione dei dati nelle tabelle. Questi dati includono i valori pi\u00f9 comuni: il numero di valori unici, informazioni sui NULL nella tabella e molte altre informazioni. <\/p>\n

<\/p>\n

Basandosi su queste statistiche, il pianificatore crea diverse query, seleziona la pi\u00f9 ottimale e utilizza questo piano di query per eseguire la query stessa e restituire i dati. <\/p>\n

<\/p>\n

A volte le statistiche possono essere imprecise. Le informazioni sulla qualit\u00e0 e sulla quantit\u00e0 possono cambiare in una tabella, ma la statistica non viene aggiornata. I piani definiti potrebbero non essere ottimali. Se i nostri piani si rivelassero non ottimali in base al monitoraggio effettuato, potremmo notare queste anomalie. Ad esempio, dove i dati sono cambiati qualitativamente e insieme all'indice \u00e8 iniziato a essere utilizzato un passaggio sequenziale nella tabella, ovvero, se la richiesta deve restituire solo 100 righe (c'\u00e8 un limite di 100), per questa richiesta verr\u00e0 eseguita una scansione completa. Questo influisce sempre negativamente sulle prestazioni. <\/p>\n

<\/p>\n

E saremo in grado di vedere questo nel monitoraggio. Potremo quindi esaminare questa richiesta, eseguire un explain, raccogliere statistiche e costruire un nuovo indice aggiuntivo. E quindi reagire al problema. Per questo \u00e8 importante. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Un altro esempio di monitoraggio. Penso che molti lo riconoscano, perch\u00e9 \u00e8 molto popolare. Chi lo usa nei propri progetti Prometheus<\/a><\/noindex>? \u0410 \u043a\u0442\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 \u044d\u0442\u043e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u043e \u0441 Prometheus? \u0414\u0435\u043b\u043e \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u0432 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u043e\u043c \u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438 \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0435\u0441\u0442\u044c \u0434\u0430\u0448\u0431\u043e\u0440\u0434 \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441 PostgreSQL \u2013 postgres_exporter<\/a><\/noindex> Prometheus. Ma c'\u00e8 un aspetto negativo. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Ci sono diversi grafici, e come unit\u00e0 sono indicati i byte, cio\u00e8 ci sono 5 grafici: Insert data, Update data, Delete data, Fetch data e Return data. Come unit\u00e0 di misura sono indicati i byte. Tuttavia, il problema \u00e8 che la statistica in PostgreSQL restituisce dati in tuple (righe). Di conseguenza, questi grafici rappresentano un modo molto efficace per ridurre il vostro carico di lavoro di diverse volte, anche decine di volte, poich\u00e9 una tuple non \u00e8 un byte, ma \u00e8 una riga, che \u00e8 composta da molti byte e ha sempre una lunghezza variabile. Pertanto, calcolare il carico di lavoro in byte utilizzando le tuple \u00e8 un compito irrealizzabile o molto complesso. Quindi, quando utilizzate il dashboard o il monitoraggio integrato, \u00e8 sempre importante capire che funzionano correttamente e restituiscono dati valutati in modo preciso. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Come si ottiene la statistica su queste tabelle? A tal fine, PostgreSQL ha un certo numero di viste. E la vista principale \u00e8 pg_stat_user_tables<\/a><\/noindex>. User_tables \u2013 significa che le tabelle sono create per conto dell'utente. In contrapposizione, ci sono le viste di sistema, che vengono utilizzate da PostgreSQL stesso. E c'\u00e8 una tabella riepilogativa Alltables, che include sia le tabelle di sistema che quelle degli utenti. Puoi partire da una delle due, quella che preferisci di pi\u00f9.<\/p>\n

<\/p>\n

Sui campi sopra indicati \u00e8 possibile valutare il numero di insert, update e delete. L'esempio di dashboard che ho utilizzato sfrutta proprio questi campi per valutare le caratteristiche del carico di lavoro. Pertanto, possiamo anche basarci su di essi. Ma \u00e8 importante ricordare che si tratta di tuple, non di byte, quindi non possiamo semplicemente convertirli in byte.<\/p>\n

<\/p>\n

Sulla base di questi dati, possiamo creare, cos\u00ec chiamate, tabelle TopN. Ad esempio, Top-5, Top-10. E possiamo monitorare quelle tabelle pi\u00f9 attive, quelle che vengono utilizzate di pi\u00f9. Ad esempio, le 5 tabelle \u2018calde\u2019 per le inserzioni. E su queste tabelle TopN valutiamo il nostro carico di lavoro e possiamo monitorare i picchi di carico di lavoro dopo vari rilasci, aggiornamenti e deployment. <\/p>\n

<\/p>\n

\u00c8 anche importante valutare le dimensioni della tabella, perch\u00e9 a volte gli sviluppatori rilasciano una nuova funzione e le nostre tabelle iniziano ad aumentare considerevolmente, poich\u00e9 decidono di aggiungere ulteriore volume di dati, senza prevedere come questo influenzer\u00e0 le dimensioni del database. Anche questi casi ci prendono di sorpresa. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

E ora una piccola domanda per voi. Qual \u00e8 la domanda che sorge quando notate un carico sul server con il database? Qual \u00e8 la successiva domanda che vi viene in mente? <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Ma in realt\u00e0 la domanda successiva \u00e8: quali sono le query che causano il carico? Cio\u00e8, non \u00e8 interessante osservare i processi che provocano il carico. \u00c8 chiaro che se hostiamo un database, l\u00ec ci sar\u00e0 in esecuzione un database e solo il database verr\u00e0 utilizzato. Se apriamo Top, vedremo un elenco di processi in PostgreSQL che stanno eseguendo delle operazioni. Da Top non sar\u00e0 chiaro cosa stanno facendo. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Pertanto, \u00e8 importante identificare le query che generano il maggior carico, poich\u00e9 l'ottimizzazione delle query di solito offre un beneficio maggiore rispetto all'ottimizzazione della configurazione di PostgreSQL, del sistema operativo o addirittura dell'hardware. A mio avviso, si tratta di circa l'80-85-90%. E questo pu\u00f2 essere fatto molto pi\u00f9 rapidamente. \u00c8 pi\u00f9 veloce correggere una query piuttosto che risistemare la configurazione, pianificare un riavvio, soprattutto se non \u00e8 possibile riavviare il database o aggiungere hardware. \u00c8 pi\u00f9 semplice riscrivere una query o aggiungere un indice per ottenere un risultato migliore da quella query. <\/p>\n

<\/p>\n

\"Fondamenti
\nDi conseguenza, \u00e8 necessario monitorare le query e la loro adeguatezza. Prendiamo un altro esempio di monitoraggio. Anche qui sembra esserci un monitoraggio eccellente. Ci sono informazioni sulla replicazione, sulla capacit\u00e0 di throughput, sui lock e sull'utilizzo delle risorse. Tutto sembra perfetto, ma mancano informazioni sulle query. Non \u00e8 chiaro quali query vengano eseguite nel nostro database, quanto tempo impiegano e quante sono. Abbiamo sempre bisogno di avere queste informazioni nel monitoraggio. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Possiamo utilizzare il modulo pg_stat_statements per ottenere queste informazioni. Da questo si possono costruire vari grafici. Ad esempio, \u00e8 possibile ottenere informazioni sulle query pi\u00f9 frequenti, cio\u00e8 su quelle eseguite pi\u00f9 spesso. S\u00ec, dopo i deployment \u00e8 anche molto utile guardarlo e capire se ci sono picchi di richieste. <\/p>\n

<\/p>\n

\u00c8 possibile monitorare le query pi\u00f9 lunghe, cio\u00e8 quelle che richiedono pi\u00f9 tempo per essere eseguite. Esse utilizzano la CPU e consumano operazioni di input\/output. Possiamo valutarle anche tramite i campi total_time, mean_time, blk_write_time e blk_read_time. <\/p>\n

<\/p>\n

Possiamo valutare e monitorare le query pi\u00f9 pesanti in termini di utilizzo delle risorse, quelle che leggono dal disco, che utilizzano la memoria o, al contrario, creano un carico di scrittura.<\/p>\n

<\/p>\n

Possiamo valutare le query pi\u00f9 gravose. Queste sono quelle query che restituiscono un numero elevato di righe. Ad esempio, pu\u00f2 trattarsi di una query in cui si \u00e8 dimenticato di impostare un limite. Essa restituir\u00e0 semplicemente tutto il contenuto della tabella o della query sulle tabelle richieste.<\/p>\n

<\/p>\n

Si pu\u00f2 anche monitorare le query che utilizzano file temporanei o tabelle temporanee. <\/p>\n

<\/p>\n

\"Fondamenti
\nE abbiamo anche processi in background. I processi in background sono innanzitutto i checkpoint, o come vengono anche chiamati, i punti di controllo, l'autovacuum e la replica. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Un altro esempio di monitoraggio. A sinistra c'\u00e8 la scheda Manutenzione, ci spostiamo su di essa e speriamo di vedere qualcosa di utile. Ma qui ci sono solo i dati sul tempo di funzionamento del vacuum e sulla raccolta delle statistiche, nient'altro. Queste sono informazioni molto scarne, quindi \u00e8 sempre necessario avere informazioni su come funzionano i processi in background nel nostro database e se ci sono problemi legati al loro funzionamento. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Quando consideriamo i punti di controllo, dobbiamo ricordare che i punti di controllo scaricano le pagine \"sporche\" dalla memoria shardata su disco, quindi creano un checkpoint. E questo checkpoint pu\u00f2 essere utilizzato come un punto di riferimento per il ripristino, nel caso in cui PostgreSQL venga chiuso in modo imprevisto. <\/p>\n

<\/p>\n

Pertanto, per scrivere tutte le pagine \"sporche\" su disco, \u00e8 necessario eseguire un certo volume di scrittura. E, di regola, nei sistemi con grande capacit\u00e0 di memoria, si tratta di un'importante quantit\u00e0. Se i nostri checkpoint vengono effettuati molto frequentemente in un intervallo di tempo breve, le prestazioni del disco subiranno notevolmente. E le richieste dei clienti soffriranno per la mancanza di risorse. Combatteranno per le risorse e mancheranno di prestazioni. <\/p>\n

<\/p>\n

Di conseguenza, attraverso pg_stat_bgwriter, possiamo monitorare il numero di checkpoint che si verificano in base ai campi specificati. E se in un certo intervallo di tempo (10-15-20 minuti, mezz'ora) ci sono molti checkpoint, per esempio, 3-4-5, questo pu\u00f2 gi\u00e0 essere un problema. \u00c8 necessario esaminare il database, controllare la configurazione per capire cosa causa tale abbondanza di checkpoint. Potrebbe essere che si stia effettuando una grande scrittura. Possiamo valutare il carico di lavoro, poich\u00e9 abbiamo gi\u00e0 aggiunto i grafici del carico di lavoro. Possiamo gi\u00e0 ottimizzare i parametri dei checkpoint e fare in modo che non influiscano troppo sulle prestazioni delle richieste.<\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Torno a parlare di autovacuum, perch\u00e9 \u00e8 un aspetto che, come gi\u00e0 detto, pu\u00f2 influenzare notevolmente le prestazioni sia dei dischi che delle query. \u00c8 quindi sempre importante valutare la quantit\u00e0 di autovacuum. <\/p>\n

<\/p>\n

Il numero di worker autovacuum in un database \u00e8 limitato. Di default ci sono tre worker; quindi, se abbiamo continuamente tre worker attivi nel database, significa che autovacuum \u00e8 sottovuoto, \u00e8 necessario aumentare i limiti, rivedere le impostazioni di autovacuum e accedere alla configurazione.
\n\u00c8 importante valutare quali worker di vacuum sono attivi. Pu\u00f2 essere che uno sia stato avviato manualmente da un DBA, creando quindi un carico aggiuntivo. Possiamo avere dei problemi. Oppure, ci sono i vacuum che registrano il conteggio delle transazioni. Per alcune versioni di PostgreSQL, questi vacuum possono essere molto pesanti. Possono influenzare notevolmente le prestazioni, poich\u00e9 leggono l'intera tabella e scandagliano tutti i blocchi in essa. <\/p>\n

<\/p>\n

E, naturalmente, la durata dei processi di vacuum. Se abbiamo vacuum prolungati che funzionano per molto tempo, significa che \u00e8 nuovamente il momento di esaminare la configurazione del vacuum e forse rivederne le impostazioni. Perch\u00e9 potrebbe verificarsi una situazione in cui il vacuum lavora su una tabella per un lungo periodo (3-4 ore), ma durante il funzionamento del vacuum si accumulano di nuovo un grande volume di righe morte. E non appena il vacuum termina, deve nuovamente eseguire il vacuum su questa tabella. Ci troviamo quindi nella situazione di un vacuum infinito. In questo caso, il vacuum non riesce a svolgere il proprio lavoro e le tabelle iniziano gradualmente a gonfiarsi in dimensioni, anche se il volume di dati utili in esse rimane lo stesso. Pertanto, in caso di vacuum prolungati, monitoriamo sempre la configurazione e cerchiamo di ottimizzarla, ma senza compromettere le prestazioni delle richieste dei clienti. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Attualmente, praticamente non esistono installazioni di PostgreSQL senza la replica streaming. La replica \u00e8 il processo di trasferimento dei dati dal master alla replica.<\/p>\n

<\/p>\n

La replica in PostgreSQL \u00e8 gestita attraverso il log delle transazioni. Il master genera il log delle transazioni. Il log viene trasmesso alla replica tramite la connessione di rete, dove viene poi riprodotto. \u00c8 tutto molto semplice. <\/p>\n

<\/p>\n

Pertanto, per monitorare il lag della replica si utilizza la vista pg_stat_replication. Tuttavia, non \u00e8 tutto cos\u00ec semplice. Nella versione 10, la vista ha subito diverse modifiche. In primo luogo, alcuni campi sono stati rinominati. Inoltre, sono stati aggiunti nuovi campi. Nella versione 10 sono stati introdotti campi che permettono di valutare il lag della replica in secondi. Questo \u00e8 molto comodo. Fino alla versione 10 era possibile valutare il lag della replica in byte. Questa opzione \u00e8 rimasta anche nella versione 10, quindi \u00e8 possibile scegliere se \u00e8 pi\u00f9 comodo valutare il lag in byte o in secondi. Molti utilizzano entrambe le modalit\u00e0.<\/p>\n

<\/p>\n

Tuttavia, per valutare il lag di replica, \u00e8 necessario conoscere la posizione del log nella transazione. Queste posizioni del log delle transazioni sono presenti nella vista pg_stat_replication. In altre parole, possiamo utilizzare la funzione pg_xlog_location_diff() per prendere due punti nel log della transazione. Calcoliamo la differenza tra di essi e otteniamo il lag di replica in byte. \u00c8 molto comodo e semplice. <\/p>\n

<\/p>\n

Nella versione 10, questa funzione \u00e8 stata rinominata in pg_wal_lsn_diff(). In generale, in tutte le funzioni, viste, utilit\u00e0 in cui appariva la parola \"xlog\", \u00e8 stata sostituita con il termine \"wal\". Questo sia nelle viste che nelle funzioni. \u00c8 una novit\u00e0. <\/p>\n

<\/p>\n

In aggiunta, nella versione 10 sono state introdotte righe che mostrano specificamente il lag. Si tratta di write lag, flush lag, replay lag. Cio\u00e8, queste metriche sono importanti da monitorare. Se vediamo che c'\u00e8 un lag di replica, dobbiamo indagare sul motivo per cui \u00e8 emerso, da dove deriva e risolvere il problema. <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Con le metriche di sistema, praticamente tutto funziona correttamente. Quando inizia qualsiasi monitoraggio, parte dalle metriche di sistema. Questi includono l'utilizzo della CPU, della memoria, dello swap, della rete e del disco. Tuttavia, mancano di molti parametri per impostazione predefinita. <\/p>\n

<\/p>\n

Se la gestione del processo \u00e8 a posto, ci sono problemi con la gestione del disco. Di solito, gli sviluppatori degli strumenti di monitoraggio aggiungono informazioni sulla larghezza di banda. Queste possono essere in iops o byte. Ma dimenticano la latenza e l'utilizzo dei dispositivi di archiviazione. Questi sono parametri pi\u00f9 importanti che consentono di valutare quanto siano occupati i dischi e quanto rallentano le operazioni. Se abbiamo un'alta latenza, significa che ci sono problemi con i dischi. Se abbiamo un'alta percentuale di utilizzo, significa che i dischi non riescono a gestire il carico.<\/strong> Queste sono caratteristiche di qualit\u00e0 superiore rispetto alla larghezza di banda.<\/p>\n

<\/p>\n

Anche se queste statistiche possono essere ottenute dal filesystem \/proc, come avviene per l'utilizzo della CPU. Non so perch\u00e9 questa informazione non venga aggiunta nei monitoraggi. Tuttavia, \u00e8 importante includerla nel proprio monitoraggio.<\/strong> <\/p>\n

<\/p>\n

Lo stesso vale per le interfacce di rete. Ci sono informazioni sulla larghezza di banda della rete in pacchetti e byte, ma non ci sono informazioni sulla latenza e sull'utilizzo, anche se queste sarebbero anch'esse utili.<\/strong> <\/p>\n

<\/p>\n

\"Fondamenti<\/p>\n

<\/p>\n

Ogni monitoraggio ha i suoi difetti. Qualunque monitoraggio tu scelga, non soddisfer\u00e0 sempre determinati criteri. Tuttavia, si stanno sviluppando, vengono aggiunte nuove funzionalit\u00e0, quindi scegli qualcosa e migliora. <\/p>\n

<\/p>\n

E per migliorare, \u00e8 sempre necessario avere una chiara comprensione di cosa significhi la statistica fornita e come questa possa essere utilizzata per risolvere i problemi. <\/p>\n

<\/p>\n

Ecco alcuni punti chiave:<\/p>\n

<\/p>\n