{"id":32353,"date":"2019-10-31T21:46:32","date_gmt":"2019-10-31T18:46:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/monitoring-proizvoditelnosti-zaprosov-postgresql-chast-1-reporting\/"},"modified":"2019-10-31T21:46:32","modified_gmt":"2019-10-31T18:46:32","slug":"monitoring-proizvoditelnosti-zaprosov-postgresql-chast-1-reporting","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/monitoring-proizvoditelnosti-zaprosov-postgresql-chast-1-reporting","title":{"rendered":"Monitoraggio delle prestazioni delle query PostgreSQL. Parte 1 - reporting","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ingegnere \u2014 in traduzione dal latino \u2014 ispirato.
\nL'ingegnere pu\u00f2 fare tutto. (c) R.Diesel.
\nEpigrafi.<\/i>
\n\"Monitoraggio
\nOppure \u00e8 una storia su perch\u00e9 un amministratore di database dovrebbe ricordare il suo passato da programmatore. <\/i><\/p>\n

Introduzione<\/h2>\n

\nTutti i nomi sono stati cambiati. Le somiglianze sono casuali. Il materiale rappresenta esclusivamente l'opinione personale dell'autore.<\/p>\n

Dichiarazione di non garanzia:<\/b> nel ciclo di articoli pianificato non ci sar\u00e0 una descrizione dettagliata e precisa delle tabelle e degli script utilizzati. I materiali non possono essere utilizzati immediatamente \"COS\u00cc COME SONO\".
\nIn primo luogo, a causa dell'ampio volume di materiale,
\nin secondo luogo a causa della specificit\u00e0 rispetto alla base di produzione del cliente reale.
\nPertanto, negli articoli verranno presentate solo idee e descrizioni in termini molto generali.
\nForse in futuro il sistema crescer\u00e0 al punto da essere pubblicato su GitHub, o forse no. Solo il tempo dir\u00e0.<\/i><\/p><\/blockquote>\n

\nInizio della storia - \"Ricordi come tutto \u00e8 iniziato<\/a><\/noindex>\u00bb.
\nCosa \u00e8 risultato alla fine, in termini molto generali - \"La sintesi come uno dei metodi per migliorare le prestazioni di PostgreSQL<\/a><\/noindex>\u00bb<\/p>\n

Perch\u00e9 tutto questo per me?<\/h2>\n

\nBeh, prima di tutto, per non dimenticare, ricordando in pensione i bei tempi.
\nIn secondo luogo, per sistematizzare ci\u00f2 che ho scritto. Perch\u00e9 gi\u00e0 da solo, a volte, inizio a confondermi e dimenticare delle parti. <\/p>\n

E, cosa pi\u00f9 importante, magari potrebbe essere utile a qualcuno e aiutare a non reinventare la ruota e non raccogliere attrezzi. In altre parole, migliorare il proprio karma (non quello di Habr). Perch\u00e9, ci\u00f2 che \u00e8 pi\u00f9 prezioso in questo mondo sono le idee. L'importante \u00e8 trovare un'idea. Realizzare un'idea nella realt\u00e0 \u00e8 gi\u00e0 una questione puramente tecnica.<\/p>\n

Dunque, iniziamo, lentamente...<\/p>\n

Definizione del problema.<\/h2>\n

<\/p>\n

Disponiamo di: <\/h3>\n

\nDatabase PostgreSQL (10.5), tipo di carico misto (OLTP+DSS), con carico medio-basso, situato nel cloud AWS.
\nLa monitoraggio del database \u00e8 assente, il monitoraggio dell'infrastruttura \u00e8 fornito dai normali strumenti AWS in configurazione minima.<\/p>\n

Richiesto:<\/h3>\n

\nMonitorare le performance e lo stato del database, trovare e avere informazioni iniziali per ottimizzare le query pesanti al DB.
\n<\/a><\/noindex><\/p>\n

Breve introduzione o analisi delle opzioni di soluzione<\/h2>\n

\nIniziamo a esaminare le opzioni di soluzione del problema dal punto di vista di un'analisi comparativa dei vantaggi e dei problemi per l'ingegnere, mentre la gestione si occupa dei benefici e delle perdite come dovrebbe essere secondo l'organizzazione.<\/p>\n

Opzione 1 - \"Lavorare su richiesta\"<\/h3>\n

\nLasciamo tutto cos\u00ec com'\u00e8. Se il cliente non \u00e8 soddisfatto di qualcosa nella funzionalit\u00e0, nelle prestazioni del database o dell'applicazione, informer\u00e0 gli ingegneri DBA via e-mail o creando un incidente nel sistema di ticketing.
\nL'ingegnere, ricevuta la notifica, si occuper\u00e0 del problema, proporr\u00e0 una soluzione o rimander\u00e0 il problema in un secondo momento, sperando che si risolva da solo e in ogni caso, presto verr\u00e0 dimenticato.
\nPasticcini e dolci, lividi e bozzi<\/b>Pasticcini e dolci:<\/b>
\n1. Non \u00e8 necessario fare nulla di superfluo
\n2. C'\u00e8 sempre l'opportunit\u00e0 di tirarsi indietro e fare finta di niente.
\n3. Una quantit\u00e0 di tempo che pu\u00f2 essere spesa a discrezione.
\nLividi e bozzi:<\/b>
\n1. Prima o poi il cliente riflette sull'essenza dell'esistenza e sulla giustizia universale in questo mondo e si pone di nuovo la domanda: per cosa sto pagando? La conseguenza \u00e8 sempre la stessa: la questione \u00e8 solo quanto il cliente si annoier\u00e0 e abbandoner\u00e0. E il sostentamento si esaurir\u00e0. \u00c8 triste.
\n2. Lo sviluppo dell'ingegnere \u00e8 zero.
\n3. Difficolt\u00e0 nella pianificazione del lavoro e del carico <\/p>\n

Opzione 2 - \"Balliamo con i tamburi, facciamo pressioni e vestiamo\"<\/h3>\n

\nPunto 1<\/b>- Perch\u00e9 abbiamo bisogno di un sistema di monitoraggio, riceveremo tutto tramite richieste. Eseguiamo un sacco di richieste verso il dizionario dei dati e le viste dinamiche, attiviamo vari contatori, raccogliamo tutto in tabelle, e periodicamente analizziamo le liste e le tabelle. In risultato abbiamo grafici belli o meno, tabelle, report. L'importante \u00e8 avere di pi\u00f9, di pi\u00f9.
\nPunto 2<\/b>- Generiamo attivit\u00e0: avviamo l'analisi di tutto questo.
\nPunto 3<\/b>- Prepariamo un documento, semplicemente lo chiamiamo \"come organizzare il database\".
\nPunto 4<\/b>- Il cliente, vedendo questa meraviglia di grafici e numeri, \u00e8 in un'innocente fiducia infantile - ora tutto funzioner\u00e0, presto. E, facilmente e senza dolore, si separa dalle sue risorse finanziarie. Anche la gestione \u00e8 sicura - i nostri ingegneri stanno lavorando sodo. Carico al massimo.
\nPunto 5<\/b>- Ripetere regolarmente il Punto 1.
\nPasticcini e dolci, lividi e bozzi<\/b>Pasticcini e dolci: <\/b>
\n1. La vita dei manager e degli ingegneri \u00e8 semplice, prevedibile e piena di attivit\u00e0. Tutto ronzante, tutti impegnati.
\n2. Anche la vita del cliente non \u00e8 male - \u00e8 sempre sicuro che basta aspettare un po' e tutto si sistemer\u00e0. Non si sistema, beh, pazienza - questo \u00e8 un mondo ingiusto, nella prossima vita andr\u00e0 meglio.
\nLividi e bozzi:<\/b>
\n1. Prima o poi, si trover\u00e0 un fornitore pi\u00f9 veloce dello stesso servizio, che far\u00e0 la stessa cosa, ma un po' pi\u00f9 economico. E se il risultato \u00e8 lo stesso, perch\u00e9 pagare di pi\u00f9? Questo porter\u00e0 ancora una volta all'estinzione della fonte di guadagno.
\n2. \u00c8 noioso. Come \u00e8 noiosa qualsiasi attivit\u00e0 poco significativa.
\n3. Come nella variante precedente, non c'\u00e8 sviluppo. Ma per l'ingegnere, il problema \u00e8 che, a differenza della prima variante, qui \u00e8 necessario generare costantemente DBI. E questo richiede tempo. Tempo che potrebbe essere speso per migliorare se stessi. Perch\u00e9 se non ti prendi cura di te stesso, agli altri non frega niente di te.<\/p>\n

Opzione 3 - Non \u00e8 necessario inventare la ruota, \u00e8 meglio comprarla e usarla.<\/h3>\n

\nGli ingegneri di altre aziende non mangiano pizza e bevono birra per niente (ah, i bei tempi di San Pietroburgo negli anni '90). Dobbiamo utilizzare sistemi di monitoraggio gi\u00e0 creati, messi a punto e funzionanti, e che in genere portano un beneficio (almeno a chi li ha creati).
\nPasticcini e dolci, lividi e bozzi<\/b>Pasticcini e dolci:<\/b>
\n1. Non \u00e8 necessario perdere tempo a inventare ci\u00f2 che \u00e8 gi\u00e0 stato inventato. Prendi e usa.
\n2. I sistemi di monitoraggio non sono scritti da stupidi e sono ovviamente utili.
\n3. I sistemi di monitoraggio funzionanti di solito forniscono informazioni utili e filtrate.
\nLividi e bozzi:<\/b>
\n1. In questo caso, l'ingegnere non \u00e8 un ingegnere, ma solo un utente di un prodotto altrui. O un user.
\n2. \u00c8 necessario convincere il cliente della necessit\u00e0 di acquistare qualcosa di cui in realt\u00e0 non vuole, n\u00e9 deve, occuparsi e il budget per l'anno \u00e8 stato approvato e non cambier\u00e0. Poi \u00e8 necessario dedicare una risorsa separata, configurare per un sistema specifico. Cio\u00e8, prima si deve pagare, pagare e pagare di nuovo. E il cliente \u00e8 avaro. Questa \u00e8 la norma della vita.<\/p>\n

Cosa fare, \u010cerny\u0161evskij? La tua domanda \u00e8 molto pertinente. (c)<\/h2>\n

\nIn questo caso specifico e nella situazione attuale, \u00e8 possibile comportarsi in modo leggermente diverso \u2014 facciamo il nostro sistema di monitoraggio. <\/b>
\n\"Monitoraggio
\nNon un sistema in senso stretto, \u00e8 troppo grossa e presuntuosa come affermazione, ma almeno alleggerire il nostro compito e raccogliere pi\u00f9 informazioni per risolvere incidenti di prestazioni. Per non trovarsi nella situazione \u2014 \u2018vai l\u00e0, non so dove, trova ci\u00f2, non so cosa\u2019.<\/p>\n

Quali sono i vantaggi e gli svantaggi di questa opzione:<\/h4>\n

Pro:<\/b>
\n1. \u00c8 interessante. Almeno \u00e8 pi\u00f9 interessante rispetto ai continui \u00abshrink datafile, alter tablespace, ecc.\u00bb
\n2. Queste sono nuove abilit\u00e0 e un nuovo sviluppo. Ci\u00f2 che, nel lungo termine, dar\u00e0 dolcetti e prelibatezze meritate.
\nContro:<\/b>
\n1. Dovremo lavorare. Lavorare tanto.
\n2. Sar\u00e0 necessario spiegare regolarmente il significato e le prospettive di tutta l'attivit\u00e0.
\n3. Dovremo sacrificare qualcosa, dato che l'unica risorsa disponibile per l'ingegnere, il tempo, \u00e8 limitata dall'Universo.
\n4. La cosa pi\u00f9 spaventosa e pi\u00f9 sgradevole<\/b> \u00e8 che potrebbe risultare una schifezza del tipo \"Non un topino, non una rana, ma una bestiolina sconosciuta\".<\/p>\n

Chi non rischia, non beve champagne.<\/b>
\nQuindi, inizia la parte pi\u00f9 interessante.<\/p>\n

L'idea generale \u00e8 schematica<\/h2>\n

\n\"Monitoraggio
\n(L'illustrazione \u00e8 tratta da un articolo<\/i> \u00abLa sintesi come uno dei metodi per migliorare le prestazioni di PostgreSQL<\/a><\/noindex>\u00bb)<\/p>\n

Spiegazione:<\/p>\n