Ti suggerisco di leggere la trascrizione del rapporto di Nikolai Samokhvalov “Approccio industriale all’ottimizzazione di PostgreSQL: esperimenti sui database”
Shared_buffers = 25% – è molto o poco? O semplicemente giusto? Come fai a sapere se questa raccomandazione, piuttosto obsoleta, è appropriata nel tuo caso particolare?
È tempo di affrontare la questione della selezione dei parametri postgresql.conf "come un adulto". Non con l'aiuto di ciechi "sintonizzatori automatici" o consigli obsoleti da articoli e blog, ma basandosi su:
- esperimenti rigorosamente verificati su database, condotti automaticamente, in grandi quantità e in condizioni il più vicino possibile a quelle di “combattimento”,
- profonda conoscenza delle funzionalità del DBMS e del sistema operativo.
Utilizzando Nancy CLI (), esamineremo un esempio specifico - i famigerati shared_buffers - in diverse situazioni, in diversi progetti e proveremo a capire come scegliere l'impostazione ottimale per la nostra infrastruttura, database e carico.
Parleremo di esperimenti con i database. Questa è una storia che dura poco più di sei mesi.
Qualcosa su di me. Esperienza con Postgres da più di 14 anni. Sono state fondate numerose società di social networking. Postgres era ed è usato ovunque.
Anche il gruppo RuPostgres su Meetup, 2° posto al mondo. Ci stiamo lentamente avvicinando a 2 persone. RuPostgres.org.
E sui PC di varie conferenze, incluso Highload, sono responsabile dei database, in particolare Postgres fin dall'inizio.
E negli ultimi anni ho riavviato il mio studio di consulenza Postgres in 11 fusi orari da qui.
E quando l'ho fatto qualche anno fa, ho avuto una pausa nel lavoro manuale attivo con Postgres, probabilmente dal 2010. Sono rimasto sorpreso da quanto poco sia cambiata la routine lavorativa di un DBA e da quanto lavoro manuale sia ancora necessario utilizzare. E ho subito pensato che qui c'era qualcosa che non andava, dovevo automatizzare di più tutto.
E poiché tutto era remoto, la maggior parte dei clienti era tra le nuvole. E molto è già stato automatizzato, ovviamente. Ne parleremo più avanti. Cioè, tutto ciò ha portato all'idea che dovrebbero esserci una serie di strumenti, cioè una sorta di piattaforma che automatizzerà quasi tutte le azioni DBA in modo da poter gestire un gran numero di database.
Questo rapporto non includerà:
- "Proiettili d'argento" e affermazioni come: imposta 8 GB o il 25% di shared_buffers e starai bene. Non ci sarà molto su shared_buffers.
- "Viscere" hardcore.
Cosa succederà
- Ci saranno principi di ottimizzazione che applicheremo e sviluppiamo. Lungo il percorso emergeranno idee di ogni genere e vari strumenti che creeremo per la maggior parte in Open Source, ovvero creiamo le basi in Open Source. Inoltre abbiamo i ticket, tutta la comunicazione è praticamente Open Source. Puoi vedere cosa stiamo facendo ora, cosa sarà nella prossima versione, ecc.
- Ci sarà anche una certa esperienza nell'utilizzo di questi principi, questi strumenti in diverse aziende: dalle piccole startup alle grandi aziende.
Come si sta sviluppando tutto questo?
In primo luogo, il compito principale di un DBA, oltre a garantire la creazione di istanze, l'implementazione dei backup, ecc., è individuare i colli di bottiglia e ottimizzare le prestazioni.
Ora è impostato così. Guardiamo il monitoraggio, vediamo qualcosa, ma ci sfugge qualche dettaglio. Iniziamo a scavare con più attenzione, di solito con le mani, e capiamo cosa farne in un modo o nell'altro.
E ci sono due approcci. Pg_stat_statements è la soluzione predefinita per identificare le query lente. E analisi dei log Postgres utilizzando pgBadger.
Ciascun approccio presenta seri inconvenienti. Nel primo approccio, abbiamo eliminato tutti i parametri. E se vediamo i gruppi SELECT * FROM tabella dove la colonna è uguale a "?" o "$" da Postgres 10. Non sappiamo se si tratta di una scansione dell'indice o di una scansione seq. Dipende molto dal parametro. Se sostituisci lì un valore incontrato raramente, sarà una scansione dell'indice. Se sostituisci lì un valore che occupa il 90% della tabella, la scansione seq sarà ovvia, perché Postgres conosce le statistiche. E questo è un grosso svantaggio di pg_stat_statements, anche se sono in corso dei lavori.
Il più grande svantaggio dell'analisi dei log è che di regola non ci si può permettere "log_min_duration_statement = 0". E parleremo anche di questo. Di conseguenza, non vedi l'intera immagine. E alcune query, che sono molto veloci, potrebbero consumare un'enorme quantità di risorse, ma non le vedrai perché sono al di sotto della tua soglia.
In che modo i DBA risolvono i problemi riscontrati?
Ad esempio, abbiamo riscontrato qualche problema. Cosa si fa solitamente? Se sei uno sviluppatore, farai qualcosa su alcune istanze che non hanno le stesse dimensioni. Se sei un DBA, allora hai la messa in scena. E può essercene solo uno. Ed era indietro di sei mesi. E pensi che andrai in produzione. E anche i DBA esperti effettuano il controllo in produzione, su una replica. E succede che creano un indice temporaneo, si assicurano che sia d'aiuto, lo rilasciano e lo danno agli sviluppatori in modo che possano inserirlo nei file di migrazione. Questo è il tipo di sciocchezza che sta accadendo adesso. E questo è un problema.
- Ottimizza le configurazioni.
- Ottimizza il set di indici.
- Modificare la query SQL stessa (questo è il modo più difficile).
- Aggiungi capacità (il modo più semplice nella maggior parte dei casi).
C'è molto da fare con queste cose. Ci sono molti handle in Postgres. C'è molto da sapere. Ci sono molti indici in Postgres, grazie anche agli organizzatori di questo convegno. E tutto questo deve essere conosciuto, e questo è ciò che fa sentire i non DBA come se i DBA praticassero la magia nera. Cioè, devi studiare per 10 anni per iniziare a capire tutto questo normalmente.
E io sono un combattente contro questa magia nera. Voglio fare tutto in modo che ci sia la tecnologia e non ci sia intuizione in tutto questo.
Esempi dalla vita
L'ho osservato in almeno due progetti, incluso il mio. Un altro post del blog ci dice che un valore pari a 1 per default_statistict_target è buono. Ok, proviamolo in produzione.
Ed eccoci qui, utilizzando il nostro strumento due anni dopo, con l'aiuto degli esperimenti sui database di cui parliamo oggi, possiamo confrontare cosa era e cosa è diventato.
E per questo dobbiamo creare un esperimento. Si compone di quattro parti.
- Il primo è l'ambiente. Abbiamo bisogno di un pezzo di hardware. E quando vengo in qualche azienda e firmo un contratto, dico loro di darmi lo stesso hardware della produzione. Per ciascuno dei tuoi Master, ho bisogno di almeno un componente hardware come questo. O si tratta di un'istanza di macchina virtuale in Amazon o Google oppure ho bisogno esattamente dello stesso componente hardware. Cioè, voglio ricreare l'ambiente. E nel concetto di ambiente includiamo la versione major di Postgres.
- La seconda parte è oggetto della nostra ricerca. Questa è una banca dati. Può essere creato in diversi modi. Ti mostrerò come.
- La terza parte è il carico. Questo è il momento più difficile.
- E la quarta parte è ciò che controlliamo, ad es. cosa confronteremo con cosa. Diciamo che possiamo modificare uno o più parametri nella configurazione oppure possiamo creare un indice, ecc.
Stiamo lanciando un esperimento. Ecco pg_stat_statements. A sinistra quello che è successo. A destra: cosa è successo.
A sinistra default_statistics_target = 100, a destra = 1. Vediamo che questo ci ha aiutato. Nel complesso, tutto è migliorato dell'000%.
Ma se scorriamo verso il basso, ci saranno gruppi di richieste da pgBadger o da pg_stat_statements. Ci sono due opzioni. Vedremo che qualche richiesta è scesa dell'88%. E qui entra in gioco l’approccio ingegneristico. Possiamo scavare più a fondo perché ci chiediamo perché sia affondato. Bisogna capire cosa è successo con le statistiche. Perché più intervalli nelle statistiche portano a risultati peggiori.
Oppure non possiamo scavare, ma facciamo "ALTER TABLE ... ALTER COLUMN" e restituiamo 100 bucket alle statistiche di questa colonna. E poi con un altro esperimento possiamo assicurarci che questa patch abbia aiutato. Tutto. Si tratta di un approccio ingegneristico che ci aiuta a vedere il quadro generale e a prendere decisioni basate sui dati piuttosto che sull’intuizione.
Un paio di esempi da altre zone. Ci sono test CI in corso da molti anni. E nessun progetto sano di mente sopravviverebbe senza test automatizzati.
In altri settori: nell'aviazione, nell'industria automobilistica, quando testiamo l'aerodinamica, abbiamo anche l'opportunità di fare esperimenti. Non lanceremo qualcosa da un disegno direttamente nello spazio, né porteremo immediatamente qualche macchina in pista. Ad esempio, c'è una galleria del vento.
Possiamo trarre conclusioni dalle osservazioni di altri settori.
Innanzitutto, abbiamo un ambiente speciale. È vicino alla produzione, ma non vicino. La sua caratteristica principale è che dovrebbe essere economico, ripetibile e quanto più automatizzato possibile. E devono esserci anche strumenti speciali per condurre analisi dettagliate.
Molto probabilmente, quando lanciamo un aereo e voliamo, abbiamo meno opportunità di studiare ogni millimetro della superficie alare rispetto a quanto ne abbiamo in una galleria del vento. Abbiamo più strumenti diagnostici. Possiamo permetterci di trasportare cose più pesanti di quelle che non possiamo permetterci di caricare su un aereo in volo. Lo stesso con Postgres. In alcuni casi potremmo abilitare la registrazione completa delle query durante gli esperimenti. E non vogliamo farlo in produzione. Potremmo anche pianificare di abilitarlo utilizzando auto_explain.
E come ho detto, un alto livello di automazione significa premere il pulsante e ripetere. Così dovrebbe essere, in modo che ci sia molta sperimentazione, in modo che sia in corso.
Nancy CLI - la fondazione del “laboratorio database”
E così abbiamo fatto questa cosa. Cioè di queste idee ho parlato a giugno, quasi un anno fa. E abbiamo già la cosiddetta Nancy CLI in Open Source. Questa è la base per costruire un laboratorio di database.
— È in Open Source, su Gitlab. Puoi dirlo, puoi provarlo. Ho fornito un collegamento nelle diapositive. Puoi cliccarci sopra e sarà lì con tutto il rispetto.
Naturalmente c’è ancora molto in fase di sviluppo. Ci sono molte idee lì. Ma questo è qualcosa che usiamo quasi ogni giorno. E quando abbiamo un'idea: perché quando eliminiamo 40 di righe, tutto si riduce a IO, quindi possiamo condurre un esperimento e osservare più in dettaglio per capire cosa sta succedendo e quindi provare a risolverlo in movimento. Cioè, stiamo facendo un esperimento. Ad esempio, modifichiamo qualcosa e vediamo cosa succede alla fine. E non lo facciamo in produzione. Questa è l'essenza dell'idea.
Dove può funzionare? Può funzionare localmente, ovvero puoi farlo ovunque, puoi persino eseguirlo su un MacBook. Ci serve uno scaricatore, andiamo. È tutto. Puoi eseguirlo in alcuni casi su un componente hardware o in una macchina virtuale, ovunque.
E c'è anche l'opportunità di eseguire da remoto Amazon in istanze EC2, in spot. E questa è un'opportunità davvero interessante. Ad esempio, ieri abbiamo condotto più di 500 esperimenti sull'istanza i3, iniziando con la più giovane e finendo con i3-16-xlarge. E 500 esperimenti ci costano 64 dollari. Ciascuno è durato 15 minuti. Cioè, a causa del fatto che lì vengono utilizzati gli spot, è molto economico: uno sconto del 70%, la fatturazione al secondo di Amazon. Puoi fare molto. Puoi fare una vera ricerca.
E sono supportate tre versioni principali di Postgres. Non è così difficile finire alcuni di quelli vecchi e anche la nuova dodicesima versione.
Possiamo definire un oggetto in tre modi. Questo:
- File dump/sql.
- Il modo principale è clonare la directory PGDATA. Di norma, viene preso dal server di backup. Se disponi di normali backup binari, puoi creare cloni da lì. Se disponi di cloud, un cloud office come Amazon e Google lo farà per te. Questo è il modo più importante per clonare la produzione reale. Ecco come ci svolgiamo.
- E l'ultimo metodo è adatto alla ricerca quando vuoi capire come funziona qualcosa in Postgres. Questo è pgbench. Puoi generare usando pgbench. È solo un'opzione "db-pgbench". Digli quale scala. E tutto sarà generato nel cloud, come detto.
E caricare:
- Possiamo eseguire il caricamento in un thread SQL. Questo è il modo più primitivo.
- E possiamo emulare il carico. E possiamo emularlo innanzitutto nel modo seguente. Dobbiamo raccogliere tutti i registri. Ed è doloroso. Ti mostrerò perché. E usando pgreplay giochiamo, che è integrato in Nancy.
- O un'altra opzione. Il cosiddetto carico artigianale, che facciamo con un certo sforzo. Analizzando il nostro attuale carico sul sistema di combattimento, estraiamo i principali gruppi di richieste. E usando pgbench possiamo emulare questo carico in laboratorio.
- O dobbiamo eseguire una sorta di SQL, ovvero controlliamo una sorta di migrazione, creiamo un indice lì, eseguiamo ANALAZE lì. E guardiamo cosa è successo prima e dopo il vuoto. In generale, qualsiasi SQL.
- O modifichiamo uno o più parametri nel file config. Possiamo dirci di controllare, ad esempio, 100 valoriin Amazon per il nostro database di terabyte. E in poche ore avrai il risultato. Di norma, ci vorranno diverse ore per distribuire un database di terabyte. Ma c'è una patch in sviluppo, ne abbiamo una serie possibile, cioè puoi utilizzare costantemente gli stessi pgdata sullo stesso server e controllare. Postgres verrà riavviato e le cache verranno ripristinate. E puoi guidare il carico.
- Arriva una directory con un mucchio di file diversi, a partire dagli snapshot pgstat***. E la cosa più interessante è pg_stat_statements, pg_stat_kcacke. Queste sono due estensioni che analizzano le richieste. E pg_stat_bgwriter contiene non solo le statistiche del pgwriter, ma anche il checkpoint e il modo in cui i backend stessi spostano i buffer sporchi. Ed è tutto interessante da vedere. Ad esempio, quando impostiamo shared_buffers, è molto interessante vedere quanto hanno sostituito tutti.
- Stanno arrivando anche i log di Postgres. Due registri: un registro di preparazione e un registro di riproduzione del caricamento.
- Una funzionalità relativamente nuova è FlameGraphs.
- Inoltre, se hai utilizzato le opzioni pgreplay o pgbench per riprodurre il caricamento, il loro output sarà nativo. E vedrai latenza e TPS. Sarà possibile capire come lo vedevano.
- Informazioni di sistema.
- Verifiche di base di CPU e IO. Questo è più vero per l'istanza EC2 in Amazon, quando vuoi avviare 100 istanze identiche in un thread ed eseguire 100 esecuzioni diverse lì, avrai 10 esperimenti. E devi assicurarti di non imbatterti in un'istanza difettosa che è già oppressa da qualcuno. Altri sono attivi su questo componente hardware e ti restano poche risorse. È meglio scartare tali risultati. E con l'aiuto di sysbench di Alexey Kopytov, eseguiamo diversi brevi controlli che arriveranno e potranno essere confrontati con altri, ad es. capirai come si comporta la CPU e come si comporta l'IO.
Quali sono le difficoltà tecniche basate sull'esempio di diverse aziende?
Diciamo che vogliamo ripetere il carico reale utilizzando i log. È un'ottima idea se è scritta su pgreplay Open Source. Lo usiamo. Ma affinché funzioni bene, è necessario abilitare la registrazione completa delle query con parametri e tempistiche.
Ci sono alcune complicazioni con la durata e il timestamp. Svuoteremo l'intera cucina. La domanda principale è se te lo puoi permettere o no?
Il problema è che potrebbe non essere disponibile. Prima di tutto, devi capire quale flusso verrà scritto nel registro. Se disponi di pg_stat_statements, puoi utilizzare questa query (il collegamento sarà disponibile nelle diapositive) per capire approssimativamente quanti byte verranno scritti al secondo.
Consideriamo la lunghezza della richiesta. Trascuriamo il fatto che non ci sono parametri, ma conosciamo la lunghezza della richiesta e sappiamo quante volte al secondo è stata eseguita. In questo modo possiamo stimare approssimativamente quanti byte al secondo. Potremmo commettere un errore doppio, ma in questo modo comprenderemo sicuramente l'ordine.
Possiamo vedere che 802 volte al secondo questa richiesta viene eseguita. E vediamo che bytes_per sec – 300 kB/s verranno scritti più o meno. E, di regola, possiamo permetterci un tale flusso.
Ma! Il fatto è che esistono diversi sistemi di registrazione. E l'impostazione predefinita delle persone è solitamente "syslog".
E se hai syslog, potresti avere un'immagine come questa. Prenderemo pgbench, abiliteremo la registrazione delle query e vedremo cosa succede.
Senza registrazione: questa è la colonna a sinistra. Abbiamo ottenuto 161 TPS. Con syslog, presente in Ubuntu 000 su Amazon, otteniamo 16.04 TPS. E se passiamo ad altri due metodi di registrazione, la situazione è decisamente migliore. Ci aspettavamo cioè che scendesse, ma non nella stessa misura.
E su CentOS 7, a cui partecipa anche journald, trasformando i log in un formato binario per una facile ricerca, ecc., allora è un incubo lì, cadiamo 44 volte in TPS.
E questo è ciò con cui convivono le persone. E spesso nelle aziende, soprattutto quelle di grandi dimensioni, questo è molto difficile da cambiare. Se puoi allontanarti da syslog, per favore allontanati da esso.
- Valutare gli IOPS e scrivere il flusso.
- Controlla il tuo sistema di registrazione.
- Se il carico previsto è eccessivamente elevato, prendere in considerazione il campionamento.
Abbiamo pg_stat_statements. Come ho detto, deve essere lì. E possiamo prendere e descrivere ogni gruppo di richieste in un modo speciale in un file. E poi possiamo usare una funzionalità molto comoda in pgbench: questa è la possibilità di inserire più file usando l'opzione "-f".
Capisce molto la "-f". E puoi dire con l'aiuto di "@" alla fine quale condivisione dovrebbe avere ogni file. Cioè possiamo dire che lo facciamo nel 10% dei casi e questo nel 20%. E questo ci avvicinerà a ciò che vediamo in produzione.
Come faremo a capire cosa abbiamo in produzione? Cosa condividere e come? Questo è un po' a parte. Abbiamo un altro prodotto . Anche una base in Open Source. E ora lo stiamo sviluppando attivamente.
È nato per ragioni leggermente diverse. Per ragioni per cui il monitoraggio non è sufficiente. Cioè vieni, guarda la base, guarda i problemi che ci sono. E, di regola, esegui un controllo dello stato di salute. Se sei un DBA esperto, esegui Health_check. Abbiamo esaminato l'uso degli indici, ecc. Se hai OKmeter, allora fantastico. Questo è un monitoraggio interessante per Postgres. OKmeter.io – per favore installalo, lì è fatto tutto molto bene. È pagato.
Se non ne hai uno, di solito non ne hai molto. Nel monitoraggio, di solito c'è CPU, IO e poi con prenotazioni, e questo è tutto. E abbiamo bisogno di altro. Dobbiamo vedere come funziona l'autovacuum, come funziona il checkpoint, in io dobbiamo separare il checkpoint dal bgwriter e dai backend, ecc.
Il problema è che quando aiuti una grande azienda, non riesce a implementare qualcosa rapidamente. Non possono acquistare rapidamente OKmeter. Forse lo compreranno tra sei mesi. Non possono consegnare rapidamente alcuni pacchi.
E ci è venuta l'idea che abbiamo bisogno di uno strumento speciale che non richieda nulla da installare, ovvero non è necessario installare nulla in produzione. Installalo sul tuo laptop o su un server di osservazione da cui lo eseguirai. E analizzerà molte cose: il sistema operativo, il file system e lo stesso Postgres, effettuando alcune query leggere che possono essere eseguite direttamente in produzione e nulla fallirà.
L'abbiamo chiamato controllo Postgres. In termini medici, questo è un controllo sanitario regolare. Se è a tema automobilistico, è come la manutenzione. Esegui la manutenzione della tua auto ogni sei mesi o un anno, a seconda della marca. Fai manutenzione alla tua base? Cioè, fai regolarmente ricerche approfondite? Deve essere fatto. Se esegui i backup, quindi esegui un controllo, questo non è meno importante.
E abbiamo uno strumento del genere. Ha cominciato ad emergere attivamente solo circa tre mesi fa. È ancora giovane, ma c'è molto da dire.
Raccolta dei gruppi di query più "influenti" - rapporto K003 in Postgres-checkup
E c'è un gruppo di rapporti K. Finora tre rapporti. E esiste un rapporto del genere K003. C'è la parte superiore di pg_stat_statements, ordinata per total_time.
Quando ordiniamo i gruppi di richieste per total_time, in alto vediamo il gruppo che carica di più il nostro sistema, cioè consuma più risorse. Perché attribuisco un nome ai gruppi di query? Perché abbiamo eliminato i parametri. Non si tratta più di richieste, ma di gruppi di richieste, cioè sono astratte.
E se ottimizziamo da cima a fondo, alleggeriremo le nostre risorse e ritarderemo il momento in cui avremo bisogno di aggiornarci. Questo è un ottimo modo per risparmiare denaro.
Forse questo non è un ottimo modo per prendersi cura degli utenti, perché potremmo non vedere casi rari, ma molto fastidiosi, in cui una persona ha aspettato 15 secondi. In totale, sono così rari che non li vediamo, ma abbiamo a che fare con risorse.
Cosa è successo in questa tabella? Abbiamo scattato due istantanee. Postgres_checkup ti fornirà un delta per ogni metrica: tempo totale, chiamate, righe, shared_blks_read, ecc. Questo è tutto, il delta è stato calcolato. Il grosso problema con pg_stat_statements è che non ricorda quando è stato ripristinato. Se pg_stat_database ricorda, allora pg_stat_statements non ricorda. Vedi che esiste un numero pari a 1, ma non sappiamo da dove abbiamo contato.
E qui lo sappiamo, qui abbiamo due istantanee. Sappiamo che il delta in questo caso è stato di 56 secondi. Un divario molto breve. Ordinati per total_time. E poi possiamo differenziare, cioè dividere tutti i parametri per la durata. Se dividiamo ogni metrica per la durata, avremo il numero di chiamate al secondo.
Successivamente, total_time al secondo è la mia metrica preferita. Si misura in secondi, al secondo, ovvero quanti secondi impiega il nostro sistema per eseguire questo gruppo di richieste al secondo. Se vedi più di un secondo al secondo lì, significa che hai dovuto fornire più di un core. Questa è una metrica molto buona. Puoi capire che questo amico, ad esempio, ha bisogno di almeno tre core.
Questo è il nostro know-how, non ho mai visto niente di simile da nessuna parte. Nota: questa è una cosa molto semplice: secondo al secondo. A volte, quando la tua CPU è al 100%, quindi mezz'ora al secondo, ovvero hai passato mezz'ora a eseguire solo queste richieste.
Successivamente vediamo le righe al secondo. Sappiamo quante righe al secondo ha restituito.
E poi c'è anche una cosa interessante. Quanti shared_buffers leggiamo al secondo dallo shared_buffers stesso. I risultati erano già presenti e abbiamo preso le righe dalla cache del sistema operativo o dal disco. La prima opzione è veloce e la seconda può essere veloce o meno, a seconda della situazione.
E il secondo modo di differenziazione è dividere il numero di richieste in questo gruppo. Nella seconda colonna avrai sempre una query divisa per query. E poi è interessante: quanti millisecondi c'erano in questa richiesta. Sappiamo come si comporta in media questa query. Per ogni richiesta sono stati necessari 101 millisecondi. Questa è la metrica tradizionale che dobbiamo comprendere.
Quante righe ha restituito in media ciascuna query? Vediamo 8 ritorni di questo gruppo. In media, quanto è stato prelevato dalla cache e letto. Vediamo che tutto è ben memorizzato nella cache. Risultati solidi per il primo gruppo.
E la quarta sottostringa in ogni riga indica la percentuale del totale. Abbiamo chiamate. Diciamo 1 e possiamo capire quale contributo dà questo gruppo. Vediamo che in questo caso il primo gruppo contribuisce per meno dello 000%. Cioè, è così lento che non lo vediamo nel quadro generale. E il secondo gruppo rappresenta il 000% sulle chiamate. Cioè, il 0,01% di tutte le chiamate appartiene al secondo gruppo.
Anche Total_time è interessante. Abbiamo dedicato il 14% del nostro tempo di lavoro totale al primo gruppo di richieste. E per il secondo - 11%, ecc.
Non entrerò nei dettagli, ma ci sono delle sottigliezze lì. Visualizziamo un errore in alto, perché quando confrontiamo, le istantanee potrebbero fluttuare, cioè alcune richieste potrebbero cadere e non essere più presenti nella seconda, mentre potrebbero apparire alcune nuove. E lì calcoliamo l'errore. Se vedi 0, allora va bene. Non ci sono errori. Se il tasso di errore è fino al 20%, va bene.
Allora torniamo al nostro argomento. Dobbiamo creare il carico di lavoro. Lo prendiamo dall'alto verso il basso e andiamo fino a raggiungere l'80% o il 90%. Di solito si tratta di 10-20 gruppi. E creiamo file per pgbench. Usiamo casuale lì. A volte questo, sfortunatamente, non funziona. E in Postgres 12 ci saranno più opportunità per utilizzare questo approccio.
E poi guadagniamo l'80-90% in total_time in questo modo. Cosa devo mettere dopo "@"? Guardiamo le chiamate, guardiamo quanto interesse c'è e capiamo che dobbiamo così tanto interesse qui. Da queste percentuali possiamo capire come bilanciare ciascuno dei file. Successivamente utilizziamo pgbench e andiamo al lavoro.
Abbiamo anche K001 e K002.
K001 è una grande stringa con quattro sottostringhe. Questa è una caratteristica di tutto il nostro carico. Vedi seconda colonna e seconda sottoriga. Lo vediamo circa un secondo e mezzo al secondo, ad es. se ci sono due core, allora andrà bene. La capacità sarà pari a circa il 75%. E funzionerà così. Se abbiamo 10 core, generalmente saremo calmi. In questo modo possiamo valutare le risorse.
K002 è ciò che chiamo classi di query, ovvero SELECT, INSERT, UPDATE, DELETE. E SELEZIONA separatamente PER L'AGGIORNAMENTO, perché è un lucchetto.
E qui possiamo concludere che SELECT è costituito da lettori ordinari: l'82% di tutte le chiamate, ma allo stesso tempo - il 74% in total_time. Cioè, si chiamano molto, ma consumano meno risorse.
E torniamo alla domanda: “Come possiamo scegliere i giusti shared_buffers?” Osservo che la maggior parte dei benchmark si basa sull'idea: vediamo quale sarà il throughput, ad es. quale sarà il throughput. Di solito viene misurato in TPS o QPS.
E proviamo a spremere quante più transazioni al secondo possibili dall'auto utilizzando i parametri di ottimizzazione. Ecco esattamente 311 al secondo per la selezione.
Ma nessuno va al lavoro e torna a casa a tutta velocità. Questo è sciocco. Lo stesso con i database. Non dobbiamo guidare a tutta velocità e nessuno lo fa. Nessuno vive nella produzione, che ha la CPU al 100%. Anche se forse qualcuno vive, ma questo non va bene.
L'idea è che di solito guidiamo al 20% della capacità, preferibilmente non più del 50%. E cerchiamo di ottimizzare soprattutto i tempi di risposta per i nostri utenti. Cioè, dobbiamo girare le nostre manopole in modo che ci sia una latenza minima al 20% della velocità, in modo condizionale. Questa è un’idea che cerchiamo di utilizzare anche nei nostri esperimenti.
E infine, raccomandazioni:
- Assicurati di fare Database Lab.
- Se possibile, fallo su richiesta in modo che si apra per un po': gioca e buttalo via. Se ci sono nuvole, questo è ovvio, cioè avere molta posizione.
- Essere curioso. E se qualcosa non va, controlla con gli esperimenti come si comporta. Nancy può essere utilizzata per allenarsi a verificare come funziona la base.
- E mira al tempo di risposta minimo.
- E non aver paura delle fonti di Postgres. Quando lavori con le fonti, devi conoscere l'inglese. Ci sono molti commenti lì, tutto è spiegato lì.
- E controlla regolarmente lo stato del database, almeno una volta ogni tre mesi, manualmente o tramite il controllo Postgres.
domande
Molte grazie! Una cosa molto interessante.
Due pezzi.
Sì, due pezzi. Solo che non ho capito bene. Quando io e Nancy lavoriamo, possiamo modificare un solo parametro o un intero gruppo?
Abbiamo un parametro di configurazione delta. Puoi girare lì quanto vuoi in una volta. Ma devi capire che quando cambi molte cose, puoi trarre conclusioni sbagliate.
SÌ. Perché l'ho chiesto? Perché è difficile condurre esperimenti quando hai un solo parametro. Stringilo, vedi come funziona. L'ho messo fuori. Quindi inizi quello successivo.
Puoi stringerlo allo stesso tempo, ma ovviamente dipende dalla situazione. Ma è meglio testare un’idea. Ieri abbiamo avuto un'idea. Avevamo una situazione molto ravvicinata. C'erano due configurazioni. E non riuscivamo a capire perché ci fosse una grande differenza. Ed è nata l'idea che è necessario utilizzare la dicotomia per comprendere e trovare costantemente qual è la differenza. Puoi immediatamente rendere uguali metà dei parametri, poi un quarto, ecc. Tutto è flessibile.
E c'è un'altra domanda. Il progetto è giovane e in via di sviluppo. La documentazione è già pronta, c'è una descrizione dettagliata?
Ho appositamente creato un collegamento lì alla descrizione dei parametri. È qui. Ma molte cose non ci sono ancora. Cerco persone che la pensano allo stesso modo. E li ritrovo quando mi esibisco. Questo è molto bello. Qualcuno sta già lavorando con me, qualcuno ha aiutato e ha fatto qualcosa lì. E se sei interessato a questo argomento, dai un feedback su ciò che manca.
Una volta costruito il laboratorio, forse ci sarà un feedback. Vediamo. Grazie!
Ciao! Grazie per la segnalazione! Ho visto che c'è il supporto Amazon. Esistono piani per sostenere l'SPG?
Buona domanda. Abbiamo iniziato a farlo. E per ora lo abbiamo congelato perché vogliamo risparmiare. Cioè, è disponibile il supporto per l'utilizzo di run on localhost. Puoi creare tu stesso un'istanza e lavorare localmente. A proposito, questo è quello che facciamo. Lo faccio a Getlab, lì a GSP. Ma non vediamo ancora il motivo di fare una tale orchestrazione, perché Google non dispone di spot economici. C'è ??? casi, ma hanno dei limiti. In primo luogo, hanno sempre solo uno sconto del 70% e lì non puoi giocare con il prezzo. Negli spot, aumentiamo il prezzo del 5-10% per ridurre la probabilità che tu venga espulso. Cioè, salvi i punti, ma possono esserti tolti in qualsiasi momento. Se fai un'offerta leggermente più alta degli altri, verrai ucciso più tardi. Google ha specifiche completamente diverse. E c'è un'altra pessima limitazione: vivono solo 24 ore. E a volte vogliamo eseguire un esperimento per 5 giorni. Ma puoi farlo in alcuni punti; i punti a volte durano mesi.
Ciao! Grazie per la segnalazione! Hai menzionato il controllo. Come si calcolano gli errori stat_statements?
Ottima domanda. Posso mostrarti e raccontarti in grande dettaglio. In breve, stiamo osservando come è fluttuato l'insieme dei gruppi di richiesta: quanti sono caduti e quanti ne sono apparsi di nuovi. E poi esaminiamo due metriche: total_time e chiamate, quindi ci sono due errori. E guardiamo al contributo dei gruppi fluttuanti. Ci sono due sottogruppi: quelli che sono partiti e quelli che sono arrivati. Vediamo qual è il loro contributo al quadro complessivo.
Non hai paura che giri lì due o tre volte nell'intervallo tra uno scatto e l'altro?
Cioè si sono registrati di nuovo o cosa?
Ad esempio, questa richiesta è già stata anticipata una volta, poi è arrivata ed è stata anticipata di nuovo, quindi è arrivata di nuovo ed è stata anticipata di nuovo. E hai calcolato qualcosa qui, e dov'è tutto?
Bella domanda, dovremo guardare.
Ho fatto una cosa simile. Ovviamente era più semplice, l'ho fatto da solo. Ma ho dovuto resettare, resettare stat_statements e capire al momento dello snapshot che c'era meno di una certa frazione, che ancora non raggiungeva il limite di quanto stat_statements poteva accumularsi lì. E da quanto ho capito, molto probabilmente non è stato spostato nulla.
Sì, sì.
Ma non capisco in quale altro modo farlo in modo affidabile.
Sfortunatamente, non ricordo esattamente se utilizziamo il testo della query lì o queryid con pg_stat_statements e ci concentriamo su quello. Se ci concentriamo su queryid, in teoria stiamo confrontando cose comparabili.
No, può essere costretto a uscire più volte tra uno scatto e l'altro e tornare di nuovo.
Con lo stesso identificativo?
Sì.
Lo studieremo. Buona domanda. Dobbiamo studiarlo. Ma per ora, ciò che vediamo è scritto 0...
Questo è, ovviamente, un caso raro, ma sono rimasto scioccato quando ho scoperto che stat_statemetns può spostarsi lì.
Ci possono essere molte cose in Pg_stat_statements. Ci siamo imbattuti nel fatto che se hai track_utility = on, anche i tuoi set vengono tracciati.
Sì, certo.
E se hai Java Hibernate, che è casuale, la tabella hash inizia a trovarsi lì. E non appena disattivi un'applicazione molto carica, ti ritroverai con 50-100 gruppi. E lì tutto è più o meno stabile. Un modo per combattere questo problema è aumentare pg_stat_statements.max.
Sì, ma devi sapere quanto. E in qualche modo dobbiamo tenerlo d'occhio. Questo è ciò che faccio. Cioè, ho pg_stat_statements.max. E vedo che al momento dello scatto non ero arrivato al 70%. Ok, quindi non abbiamo perso nulla. Ripristiniamo. E salviamo ancora. Se lo snapshot successivo è inferiore a 70, molto probabilmente non hai perso più nulla.
SÌ. Il valore predefinito ora è 5. E questo è sufficiente per molte persone.
Di solito sì.
Video:
PS A mio nome, aggiungo che se Postgres contiene dati riservati e non può essere incluso nell'ambiente di test, puoi utilizzare . Lo schema è approssimativamente il seguente:
Fonte: habr.com