PostgreSQL Long VACUUM

Question

Attualmente sto ripulendo una tabella con 2 indici e 250 milioni di righe attive e circa altrettante righe morte (o più). Ho emesso il comando VACCUM FULL ANALYZE dal mio computer client (laptop) al mio server. Ha fatto i suoi affari negli ultimi 3-4 giorni circa; Mi chiedo se finirà presto quando avrò molto lavoro da fare!

Il server ha un processore Xeon quad-code da 2,66 GHz, 12 GB o RAM e un controller RAID collegato a 2 unità SAS SAS da 10 GB rpm da 146 GB in una configurazione RAID 1; sta eseguendo Suse Linux. Mi chiedo ...

Ora, in primo luogo, il processo postmaster VACUUM sembra utilizzare solo un core. In secondo luogo, non vedo scritture di I / O molto elevate nel rapporto tempo di inattività I / O. In terzo luogo, chiamando il procinfo , posso estrapolare che il processo VACUUM passi la maggior parte del suo tempo (88%) in attesa di I / 0.

Quindi perché non utilizza più core attraverso i thread per sovraccaricare il controller RAID (ottenere scritture I / O elevate in rapporto di inattività)? Perché è in attesa di I / O se il carico I / O non è elevato? Perché non sta andando più veloce con tutto questo potere / risorse a portata di mano? Mi sembra che VACUUM possa e debba essere multithread, specialmente se sta lavorando su un tavolo enorme ed è l'unico che funziona!

Inoltre, è un modo per configurare postgresql.conf in modo da consentire il multithread di questi VACUUM? Posso ucciderlo e comunque beneficiare della sua parziale pulizia? Devo lavorare su quel tavolo.

[Sto usando PostgreSQL 8.1]

Ancora grazie

Answer 1

Non dici quale versione di PostgreSQL stai usando. È possibile che sia pre-8.0?

Ho avuto lo stesso identico scenario. Il tuo meglio:

• uccidi il vuoto
• esegui il backup della tabella con l'opzione pg_dump -t
• rilascia la tabella
• ripristina la tabella

Se stai usando 8.x, guarda le opzioni di autovacuum. Il vuoto è a thread singolo, non c'è niente che tu possa fare per farlo usare più thread.

Answer 2

Alcuni suggerimenti rapidi:

• Esegui VACUUM FULL VERBOSE in modo da poter vedere cosa sta succedendo.
• Elimina tutti gli indici prima del VUOTO. È più veloce ricostruirli che aspirarli. Devi anche ricostruirli di tanto in tanto perché VACUUM FULL non è abbastanza buono (specialmente su un vecchio PosgreSQL come 8.1).
• Imposta il valore_misura_lavoro davvero alto.
• Utilizza un PostgreSQL più recente. A proposito, 8.4 avrà un enorme miglioramento nell'aspirazione.

Un'alternativa a VACUUM è scaricare e ripristinare.

Modifica: da 9.0 VACUUM FULL riscrive l'intera tabella. È praticamente la stessa cosa di fare un dump + restore, quindi eseguire REINDEX non è necessario.

Answer 3

Sei sicuro di non avere nulla in corso che possa bloccare le tabelle e impedire il funzionamento del vuoto?

(Ad ogni modo, è meglio usare vacuum_cost_delay in modo che il vuoto non interferisca con la produzione.)

Answer 4

Il vecchio VUOTO COMPLETO è un fossile. È anche piuttosto lento e dopo devi reindicizzare. Non usarlo. Se vuoi veramente deframmentare una tabella, usa CLUSTER o questo:

Lettssay ti resta un po 'di spazio su disco, molto più veloce di dump & ricaricare:

CREATE TABLE newtable AS SELECT * FROM oldtable;
CREATE INDEX bla ON newtable( ... );
ALTER TABLE oldtable RENAME TO archive;
ALTER TABLE newtable RENAME TO oldtable;

Nota che questo non copierà i tuoi vincoli. Puoi usare CREATE TABLE LIKE ... per copiarli.

  

Quindi perché non utilizza più core tramite thread

pg non supporta questo.