Cómo hacer que pg_dump sea menos codicioso de recursos

He configurado cron para invocar pg_dump a diario utilizando la siguiente regla:

# 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

Básicamente funciona. La base de datos crece relativamente rápido y exponencialmente (sin embargo, el exponente no es muy grande). Actualmente, el volcado gzipped ocupa unos 160 MB. Cuando se descarga la base de datos, el sistema comienza a gatear. El promedio de carga que vi usando el topcomando era aproximadamente 200, 200, 180. Básicamente, el servidor apenas responde.

La primera pregunta es cómo determinar dónde está el cuello de botella. ¿Es el bajo rendimiento causado por operaciones pesadas de E / S? ¿Es causado por problemas de bloqueo de la tabla? Tal vez es un problema de memoria? La salida del pg_dumpcomando se canaliza al gzipcomando. ¿Es secuencial, es decir, todo el volcado se coloca en la memoria (¿problema de intercambio?) Y luego se comprime o concurre (es decir, gzip comprime lo que se obtiene y espera más)? ¿Puede ser causado por algún otro factor?

La segunda pregunta es cómo hacer que la operación de descarga sea menos intrusiva para las funciones principales del sistema. Por lo que yo entiendo, el volcado no puede tomar demasiado tiempo debido a la integridad de la base de datos. Hay bloqueos de escritura de tabla, etc. ¿Qué puedo hacer para limitar los problemas (o retrasarlo, considerando el crecimiento de la base de datos)?

La tercera pregunta : ¿ya es hora de aprender sobre configuraciones de bases de datos más avanzadas? El sistema funciona bien, cuando no se realizan copias de seguridad de la base de datos, pero ¿tal vez el problema de db dump es un primer síntoma de problemas entrantes?

Guau. Increíble número de preguntas. Intentaré abordar algunas, pero esta respuesta aún no está completa.

cómo determinar dónde está el cuello de botella.

Use topprimero para ver qué sucede durante el volcado. Inspeccione el uso de la CPU del proceso, el estado del proceso. Dsignifica "esperando E / S".

¿Es el bajo rendimiento causado por operaciones pesadas de E / S?

Si, muy probablemente.

¿Es causado por problemas de bloqueo de la tabla?

Tal vez. podría usar la pg_stat_activityvista del sistema para ver qué sucede en postgres durante el volcado.

Tal vez es un problema de memoria?

Muy improbable

La salida del comando pg_dump se canaliza al comando gzip. ¿Es secuencial, es decir, todo el volcado se coloca en la memoria (problema de intercambio?)

No. gzip es un compresor de bloque que funciona en modo continuo, no mantiene todas las entradas en la memoria.

y luego comprimido o concurrente (es decir, gzip comprime lo que obtiene y espera más)?

Sí, comprime bloque por bloque, produce salidas y espera más.

¿Puede ser causado por algún otro factor?

Si.

Por lo que yo entiendo, el volcado no puede tomar demasiado tiempo debido a la integridad de la base de datos. Hay bloqueos de escritura de tabla, etc. ¿Qué puedo hacer para limitar los problemas (o retrasarlo, considerando el crecimiento de la base de datos)?

La duración del volcado no tiene ningún efecto sobre la integridad del volcado. La integridad se garantiza mediante el uso de una transacción con nivel de aislamiento de lectura repetible por todo el proceso pg_dump. NO hay bloqueos de escritura de tabla.

¿Ya es hora de aprender sobre configuraciones de bases de datos más avanzadas? El sistema funciona bien, cuando no se realizan copias de seguridad de la base de datos, pero ¿quizás el problema de volcado de db es un primer síntoma de problemas entrantes?

Nunca demasiado tarde. Comience con http://wiki.postgresql.org/wiki/Performance_Optimization .

Le recomiendo que mire el archivo continuo de postgresql. Estas son las ventajas sobre el uso de pg_dump:

1. No es necesario hacer una copia de seguridad completa cada vez. Una copia de seguridad completa es suficiente al principio, pero se recomienda tener una copia de seguridad completa cada varios días, por ejemplo.
2. Mucho más rápido de restaurar cuando la base de datos crece en tamaño.
3. La capacidad de restaurar a otro punto (recuperación en un punto en el tiempo).
4. Hará copias de seguridad incrementales cada hora (aproximadamente 30 minutos). Esto se puede configurar y depende también de la actividad de actualización.

Sin embargo, hay algunos inconvenientes (que podrían no ser un problema en la mayoría de los casos):

1. Por lo general, se requiere más espacio porque se trata de copias de seguridad binarias. La carpeta DB se puede comprimir.
2. No puede restaurarlos en una arquitectura diferente (datos binarios).