Comment rendre pg_dump moins gourmand en ressources

J'ai configuré cron pour appeler pg_dump quotidiennement en utilisant la règle suivante:

# 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

Fondamentalement, cela fonctionne. La base de données se développe relativement rapidement et de façon exponentielle (cependant l'exposant n'est pas très grand). Actuellement, le vidage compressé prend environ 160 Mo. Lorsque la base de données est vidée, le système commence à analyser. La moyenne de charge que j'ai vue en utilisant la topcommande était d'environ 200, 200, 180. Fondamentalement, le serveur est à peine réactif.

La première question est de savoir comment déterminer où se trouve le goulot d'étranglement. Les mauvaises performances sont-elles causées par de lourdes opérations d'E / S? Est-ce dû à des problèmes de verrouillage de table? C'est peut-être un problème de mémoire? La sortie de la pg_dumpcommande est dirigée vers la gzipcommande. Est-ce séquentiel, c'est-à-dire que le vidage entier est placé dans la mémoire (problème de permutation?) Puis compressé ou simultané (c'est-à-dire que gzip compresse ce qu'il obtient et attend plus)? Peut-elle être causée par un autre facteur?

La deuxième question est de savoir comment rendre l'opération de dumping moins intrusive pour les principales fonctions du système. Pour autant que je comprends les choses, le vidage ne peut pas prendre trop de temps en raison de l'intégrité de la base de données. Il existe des verrous d'écriture de table, etc. Que puis-je faire pour limiter les problèmes (ou les retarder, compte tenu de la croissance de la base de données).

La troisième question : Est - il déjà temps d'apprendre sur les configurations de base de données plus avancées? Le système fonctionne bien, lorsque les sauvegardes de base de données ne sont pas effectuées, mais peut-être que le problème de vidage de la base de données est un premier symptôme de problèmes entrants?

Sensationnel. Un nombre incroyable de questions. Je vais essayer de répondre à certains, mais cette réponse n'est pas encore complète.

comment déterminer où se trouve le goulot d'étranglement.

Utilisez d' topabord pour voir ce qui se passe pendant le vidage. Inspectez l'utilisation du processeur du processus, l'état du processus. Dsignifie "en attente d'E / S".

Les mauvaises performances sont-elles causées par de lourdes opérations d'E / S?

Oui, très probablement.

Est-ce causé par des problèmes de verrouillage de table?

Peut être. vous pouvez utiliser la pg_stat_activityvue système pour voir ce qui se passe dans postgres pendant le vidage.

C'est peut-être un problème de mémoire?

Très improbable.

La sortie de la commande pg_dump est dirigée vers la commande gzip. Est-ce séquentiel, c'est-à-dire que le vidage entier est placé dans la mémoire (problème de permutation?)

Non. Gzip est un compresseur de blocs fonctionnant en mode flux, il ne conserve pas toutes les entrées en mémoire.

puis compressé ou simultané (c'est-à-dire que gzip compresse ce qu'il obtient et attend plus)?

Oui, il comprime bloc par bloc, sort et attend plus.

Peut-elle être causée par un autre facteur?

Oui.

Pour autant que je comprends les choses, le vidage ne peut pas prendre trop de temps en raison de l'intégrité de la base de données. Il existe des verrous d'écriture de table, etc. Que puis-je faire pour limiter les problèmes (ou les retarder, compte tenu de la croissance de la base de données).

La durée du vidage n'a aucun effet sur l'intégrité du vidage. L'intégrité est assurée en utilisant une transaction avec un niveau d'isolation de lecture répétable par tous les processus pg_dump. Il n'y a AUCUN verrou d'écriture de table.

Est-il déjà temps d'en apprendre davantage sur les configurations de base de données plus avancées? Le système fonctionne bien, lorsque les sauvegardes de base de données ne sont pas effectuées, mais peut-être que le problème de vidage de la base de données est un premier symptôme de problèmes entrants?

Jamais trop tard. Commencez avec http://wiki.postgresql.org/wiki/Performance_Optimization .

Je vous recommande de regarder l'archivage continu de postgresql. Voici les avantages par rapport à l'utilisation de pg_dump:

1. Pas besoin de faire une sauvegarde complète à chaque fois. Une sauvegarde complète suffit au début, mais il est recommandé d'avoir une sauvegarde complète tous les plusieurs jours par exemple.
2. Restauration beaucoup plus rapide lorsque la taille de la base de données augmente.
3. La possibilité de restaurer à un autre point (récupération ponctuelle).
4. Vous effectuerez une sauvegarde incrémentielle toutes les heures (environ 30 minutes). Cela peut être configuré et dépend également de l'activité de mise à jour.

Cependant, il y a quelques inconvénients (qui pourraient ne pas être un problème dans la plupart des cas):

1. Habituellement, plus d'espace est requis car il s'agit de sauvegardes binaires. Le dossier DB peut être compressé.
2. Vous ne pouvez pas les restaurer sur une architecture différente (données binaires).