Come rendere pg_dump meno avido di risorse

Ho configurato cron per invocare pg_dump su base giornaliera usando la seguente regola:

# xyz database backups:
00 01 * * * root umask 077 && pg_dump --user=xyz_system xyz | gzip > /var/xyz/backup/db/xyz/`date -u +\%Y\%m\%dT\%H\%M\%S`.gz

Fondamentalmente funziona. Il database cresce relativamente velocemente ed esponenzialmente (tuttavia l'esponente non è molto grande). Attualmente la discarica gzip richiede circa 160 MB. Quando il database viene scaricato, il sistema inizia a eseguire la scansione. La media del carico che ho visto usando il topcomando era circa 200, 200, 180. Fondamentalmente il server è poco reattivo.

La prima domanda è come determinare dove si trova il collo di bottiglia. Le scarse prestazioni sono causate da pesanti operazioni di I / O? È causato da problemi di blocco della tabella? Forse è un problema di memoria? L'output del pg_dumpcomando viene reindirizzato al gzipcomando. È sequenziale, ovvero l'intero dump viene inserito nella memoria (problema di scambio?) E quindi compresso o simultaneo (ovvero gzip comprime ciò che ottiene e attende di più)? Potrebbe essere causato da qualche altro fattore?

La seconda domanda è come rendere l'operazione di dumping meno invadente per le principali funzioni del sistema. Per quanto ho capito, il dump non può richiedere troppo tempo a causa dell'integrità del database. Esistono blocchi di scrittura delle tabelle, ecc. Cosa posso fare per limitare i problemi (o ritardarli, considerando la crescita del database).

La terza domanda : è già tempo di conoscere configurazioni di database più avanzate? Il sistema funziona bene, quando i backup del database non vengono eseguiti, ma forse il problema del dumping db è un primo sintomo di problemi in arrivo?

Wow. Numero incredibile di domande. Proverò ad affrontarne alcuni, ma questa risposta non è ancora completa.

come determinare dove si trova il collo di bottiglia.

Usa topprima per vedere cosa succede durante il dump. Ispezionare l'utilizzo della CPU del processo, lo stato del processo. Dsignifica "in attesa di I / O".

Le scarse prestazioni sono causate da pesanti operazioni di I / O?

Sì, molto probabilmente.

È causato da problemi di blocco della tabella?

Può essere. potresti usare la pg_stat_activityvista di sistema per vedere cosa succede in Postgres durante il dump.

Forse è un problema di memoria?

Molto spiacevole.

L'output del comando pg_dump viene reindirizzato al comando gzip. È sequenziale, ovvero l'intero dump viene inserito nella memoria (problema di scambio?)

No. gzip è un compressore a blocchi che funziona in modalità stream, non mantiene tutti gli input in memoria.

e quindi compresso o simultaneo (cioè gzip comprime ciò che ottiene e aspetta di più)?

Sì, comprime blocco per blocco, emette e attende di più.

Potrebbe essere causato da qualche altro fattore?

Sì.

Per quanto ho capito, il dump non può richiedere troppo tempo a causa dell'integrità del database. Esistono blocchi di scrittura delle tabelle, ecc. Cosa posso fare per limitare i problemi (o ritardarli, considerando la crescita del database).

La durata del dump non ha alcun effetto sull'integrità del dump. L'integrità è garantita utilizzando una transazione con livello di isolamento di lettura ripetibile da tutto il processo pg_dump. Non ci sono blocchi di scrittura della tabella.

È già tempo di conoscere configurazioni di database più avanzate? Il sistema funziona bene, quando i backup del database non vengono eseguiti, ma forse il problema del dumping db è un primo sintomo di problemi in arrivo?

Mai troppo tardi. Inizia con http://wiki.postgresql.org/wiki/Performance_Optimization .

Ti consiglio di consultare l' archiviazione continua di postgresql. Ecco i vantaggi rispetto all'utilizzo di pg_dump:

1. Non è necessario eseguire un backup completo ogni volta. Un backup completo è sufficiente all'inizio, ma ad esempio si consiglia di avere un backup completo ogni diversi giorni.
2. Ripristino molto più rapido quando le dimensioni del DB aumentano.
3. La possibilità di ripristinare in qualche altro punto (Ripristino temporizzato).
4. Farai un backup incrementale ogni ora (circa 30 minuti). Questo può essere configurato e dipende anche dall'attività di aggiornamento.

Tuttavia, ci sono alcuni svantaggi (che nella maggior parte dei casi potrebbero non rappresentare un problema):

1. Di solito è necessario più spazio perché si tratta di backup binari. La cartella DB può essere compressa.
2. Non è possibile ripristinarli su un'architettura diversa (dati binari).