Come rendere pg_dump less risorse avidi

Ho configurato cron per invocare pg_dump su base giornaliera utilizzando 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 veloce ed esponenziale (tuttavia l'esponente non è molto grande). Attualmente il dump di gzipping dura circa 160 MB. Quando il database viene scaricato, il sistema inizia a eseguire la scansione. La media di carico che ho visto usando il command top era di circa 200, 200, 180 . Fondamentalmente il server è difficilmente reattivo.

La prima domanda è come determinare where si trova il collo di bottiglia. È la scarsa prestazione causata da operazioni di I / O pesanti? È causato da problemi di block del tavolo? Forse è un problema di memory? L'output del command pg_dump viene inviato al command gzip . È sequenziale, cioè l'integer dump viene inserito nella memory (problema di scambio?) E poi compresso o concorrente (cioè gzip comprime ciò che ottiene e attende di più)? Può essere causato da un altro fattore?

La seconda domanda è come rendere l'operazione di dumping less invadente per le principali funzioni del sistema. Per quanto riguarda le cose, il deposito non può richiedere troppo tempo a causa dell'integrità del database. Ci sono blocchi di scrittura a table, ecc. Cosa posso fare per limitare i problemi (o ritardarlo, considerando la crescita del database).

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

  • Come scalare in modo efficiente i dati di OpenStreetMap
  • postgresql blocca gammu-smsd con errore di codifica
  • Come faccio a sapere se l'autovacuumer in postgres 8.3 sta funzionando?
  • PostgreSQL: come elenco i nomi delle banche dati?
  • psql: FATAL: imansible scrivere file init
  • Arrestare il contenitore postgresql
  • Il servizio PostgreSQL initdb non funziona
  • Strategia di backup di PostgreSQL EC2
  • 2 Solutions collect form web for “Come rendere pg_dump less risorse avidi”

    Wow. Sorprendente numero di domande. Cercherò di affrontare alcuni, ma questa risposta non è ancora completa.

    come determinare where si trova il collo di bottiglia.

    Utilizza prima la parte top per vedere cosa succede durante il dump. Controllare l'utilizzo della CPU, lo stato del process. D significa "in attesa di I / O".

    È la scarsa prestazione causata da operazioni di I / O pesanti?

    Sì, molto probabilmente.

    È causato da problemi di block del tavolo?

    Può essere. è ansible utilizzare la vista del sistema pg_stat_activity per vedere cosa sta succedendo in postgres durante il dump.

    Forse è un problema di memory?

    Molto spiacevole.

    L'output del command pg_dump viene inviato al command gzip. È sequenziale, ossia l'integer dump viene inserito nella memory (problema di scambio?)

    No. gzip è un compressore di blocchi che funziona in modalità stream, non tiene tutti gli input in memory.

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

    Sì, blocca block per block, uscisce e attende di più.

    Può essere causato da un altro fattore?

    Sì.

    Per quanto riguarda le cose, il deposito non può richiedere troppo tempo a causa dell'integrità del database. Ci sono blocchi di scrittura a table, ecc. Cosa posso fare per limitare i problemi (o ritardarlo, considerando la crescita del database).

    La durata della discarica non ha alcun effetto sull'integrità dump. L'integrità è assicurata usando una transazione con livello di isolamento di lettura ripetibile da tutti i processi pg_dump. Non ci sono serrature per la scrittura del tavolo.

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

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

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

    1. Non c'è bisogno di fare un backup completo each volta. Un primo backup è abbastanza all'inizio, ma è consigliabile avere un backup completo, ad esempio, each giorno.
    2. Molto più veloce da ripristinare quando il DB cresce in size.
    3. La capacità di ripristinare in un altro punto (ripristino in tempo reale).
    4. Verrà eseguito il backup incrementale each ora (30 minuti circa). Questo può essere configurato e dipende anche dall'attività di aggiornamento.

    Tuttavia, ci sono alcuni inconvenienti (che in molti casi potrebbero non essere un problema):

    1. Di solito è necessario più spazio perché questi sono backup binari. La cartella DB può essere compressa.
    2. Non è ansible ripristinarli su un'architettura diversa (dati binari).
    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.