Uso un software che crea un grande database PostgreSQL (contiene una tabella con un milione di righe) e gli sviluppatori dicono che dovrei VACUUMe ANALYZEperiodicamente. Ma il database PostgreSQL predefinito è autovacuumattivato.
Devo aspirare / analizzare affatto? Quali sono i vantaggi? Qual è la differenza tra vuoto automatico e manuale
Ad esempio, in Pgadmin3, ho questo:
Risposte:
Concordo con ETL che non esiste una risposta breve. Le dimensioni non sono l'unica cosa che conta: eseguiamo database OLTP PostgreSQL piuttosto grandi (con alcune tabelle> 100.000.000 di righe) sotto carico pesante e attualmente contiamo solo su autovacuum.
Tuttavia, due cose sembrano importanti per me:
Sembra esserci un consenso sul fatto che l'autovacuum non dovrebbe mai essere spento, a meno che tu non abbia un carico di lavoro molto ben definito nel tuo database e sai esattamente cosa stai facendo. Ma, naturalmente, potresti fare ulteriori VACUUMe / o ANALYZEcorse.
Prima di prendere in considerazione ulteriori VACUUMesecuzioni, verificherei come mantiene l'autovacuum. È possibile verificare se le tabelle superano la soglia di vuoto automatico eseguendo una query pg_stat_user_tablese pg_class. Ho pubblicato una query del genere su un altro thread, che potrebbe essere di interesse: Aggressive Autovacuum su PostgreSQL .
Sfortunatamente, non è così facile (cioè non possibile al momento) fare un controllo simile per le soglie di analisi automatica. Tuttavia, per impostazione predefinita, l'autoanalyze prende il via molto prima dell'autovacuum ed è molto più economico. Quindi, fondamentalmente se il tuo database può tenere il passo con autovacuum, probabilmente andrà bene anche con l'analisi automatica. È inoltre possibile eseguire una query sulle ultime date di analisi automatica pg_stat_user_tables.
Alcune parti della (più eccellente) documentazione PostgreSQL, che ho trovato utile:
Autovacuum dovrebbe coprirlo abbastanza bene, a meno che tu non abbia configurato male qualcosa. Altre risposte lo riguardano già.
Esiste un caso chiaramente definito per manuale VACUUM (e, soprattutto: manuale ANALYZE): tabelle temporanee , che non sono considerate dal demone autovacuum. Cito il manuale CREATE TABLEqui :
Il demone autovacuum non può accedere e quindi non può aspirare o analizzare tabelle temporanee. Per questo motivo, le operazioni di analisi e vuoto appropriate devono essere eseguite tramite i comandi SQL della sessione. Ad esempio, se una tabella temporanea verrà utilizzata in query complesse, è consigliabile eseguirla
ANALYZEsulla tabella temporanea dopo che è stata popolata.
Non c'è una risposta breve a ciò in quanto dipende da molti fattori. Il sistema è lento? L'aspirapolvere sta effettivamente toccando questa tabella? eccetera.
Ecco alcuni buoni collegamenti su questo argomento:
Per prendere una decisione chiara richiede una comprensione del database stesso e maggiori dettagli su ciò che sta succedendo.
Non penso che sia necessario aspirare manualmente, a meno che non si inizi a vedere un peggioramento delle prestazioni. Tuttavia, consiglio vivamente di rivedere le impostazioni del vuoto e del vuoto automatico e modificarlo in base alle proprie esigenze
Per visualizzare le tue impostazioni correnti, esegui questa query:
SELECT *
FROM pg_settings
WHERE name LIKE '%vacuum%'La maggior parte dei campi si spiega da sé, ma ecco la documentazione su di essi: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html
Direi che il tuo obiettivo dovrebbe essere quello di configurare l'autovacuum per pulire la spazzatura in modo coerente, ma non eseguire costantemente l'autovacuum
Le impostazioni più importanti sono:
La soglia aiuta a impedire che il processo di pulizia venga attivato troppo spesso per i tavoli di piccole dimensioni.
Le impostazioni predefinite funzionano bene, a meno che tu non abbia tabelle molto grandi. In poche parole, se ti capita di avere una tabella che richiede 100 GB, accumulerai rifiuti da 20 GB, prima che venga attivato il vuoto automatico. Pertanto, di solito consiglio di impostare un fattore di scala basso. Quanto in basso dovresti determinare da solo. Uso 0,05 sul mio progetto attuale
Le soglie possono anche essere aumentate. Molte applicazioni hanno un paio di tabelle, che vengono spesso aggiornate e 50 tuple non sono poi così tante. Aumentare quello a 1000 non dovrebbe comportare alcun problema, ma ovviamente dovresti considerare il tuo caso
Puoi anche mettere a punto l'autovacuum e avere impostazioni diverse per alcuni dei tuoi tavoli
ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);Se configuri scale_factor e soglie dovresti andare bene. È inoltre possibile aumentare autovacuum_vacuum_cost_limit, che per impostazione predefinita è uguale a vacuum_cost_limit, che è impostato su 200. Questa è una caratteristica molto importante del vuoto, che non consente di consumare tutte le risorse e consente all'applicazione di operare con i dati anche durante il processo di aspirazione , ma il valore predefinito è troppo basso. L'aumento a 1000 non dovrebbe comportare ritardi significativi, ma consentirà al processo del vuoto di terminare molto più velocemente
Naturalmente, puoi anche eseguire il vuoto manualmente. In un caso molto semplice, puoi avere un semplice cron job, che effettuerà una pulizia completa ogni notte, quando al tuo DB non si accede frequentemente
Spero possa aiutare!