Forum Linux.général Pipe et utilisation mémoire

Posté par . Licence CC by-sa.
Tags : aucun
2
18
juil.
2018

Bonjour,

Pour sauvegarder ma base PostgreSQL dans un fichier aussi petit que possible je fais un pg_dump -Fp (format texte) dans un fichier puis je compresse le résultat avec lzma -2.
Le temps de traitement, l'utilisation mémoire, cpu et la taille du dump compressé sont acceptables.

En revanche cela nécessite un fichier dump temporaire non compressé de 70 Go et l'espace disque commence à manquer.

Mon idée serait donc de me passer du fichier temporaire et d'utiliser un pipe, un truc du genre: pg_dump -Fp | lzma -2

Quel est votre avis là dessus ? Cela risque-t-il de saturer la mémoire ou d'augmenter le temps de traitement ?

Je pourrais faire des essais mais la base est tellement grosse que c'est une vraie plaie de la restaurer, et je suis un peu réticent à faire mes tests directement sur la prod.

Merci pour vos retours.

  • # Le tuyau est rigide

    Posté par (page perso) . Évalué à 4 (+3/-0).

    Un pipe ne fait que rediriger la sortie standard d'un programme vers l'entrée standard d'un autre. Il ne consomme pas vraiment de mémoire en lui même. La question est plus de savoir si pg_dump bufferise sa sortie ou lzma son entrée. Avec lzma d'après le man tu peux limiter l'utilisation mémoire avec l'option --memlimit, ça devrait donc te permettre de limiter l'utilisation mémoire.

  • # pg_dump -Fp ?

    Posté par . Évalué à 2 (+1/-0). Dernière modification le 19/07/18 à 09:35.

    Tu fais un backup au format "plain" - c'est relativement verbeux…

    Tu as une bonne raison de ne pas utiliser le format "Custom" (flag -Fc), qui est compressé nativement? Accessoirement, il te permet aussi de faire du pg_restore -j (pour utiliser plusieurs jobs en parallèle, ça peut rendre la restauration plus rapide)

    • [^] # Re: pg_dump -Fp ?

      Posté par (page perso) . Évalué à 4 (+1/-0).

      Mieux encore, le format répertoire -Fd, qui est également compressé, mais qui est en plus parallélisable, non seulement à la restauration, mais également au moment où tu le fais !

      • [^] # Re: pg_dump -Fp ?

        Posté par . Évalué à 3 (+1/-0).

        Et en plus il est "rsync friendly", si d'un backup à l'autre le contenu d'une table n'a pas changé, le fichier contenant ses données sera identique.

        Et j'ajouterai qu'avec tous les formats de backups autre que plain (donc custom, tar et directory), la restauration avec pg_restore peut être partielle de façon très fine (voir la doc de pg_restore).

    • [^] # Re: pg_dump -Fp ?

      Posté par . Évalué à 1 (+0/-0). Dernière modification le 19/07/18 à 18:51.

      Bonjour,

      J'utilise plain + compression pour obtenir un fichier plus petit qu'avec l'option custom de pg_dump.
      Je crois que pg_dump utilise gzip pour faire la compression et lzma semble plus performant.

      • [^] # Re: pg_dump -Fp ?

        Posté par (page perso) . Évalué à 2 (+1/-0).

        Pour toutes les raisons expliquées par les autres gens dans ce thread, ce n'est pas une très bonne idée.

        Tu vas gagner un peu en compression mais perdre beaucoup en flexibilité : par exemple si tu dois ne restaurer qu'une seule table, c'est très facile avec les autres formats, très pénible avec un format texte.

        Je conseille vraiment d'éviter le format texte autant que possible, ça te sauvera la vie plus d'une fois.

        • [^] # Re: pg_dump -Fp ?

          Posté par . Évalué à 2 (+0/-0). Dernière modification le 20/07/18 à 10:55.

          J'utilise plain + compression pour obtenir un fichier plus petit qu'avec l'option custom de pg_dump.
          Je crois que pg_dump utilise gzip pour faire la compression et lzma semble plus performant.

          Je conseille vraiment d'éviter le format texte autant que possible, ça te sauvera la vie plus d'une fois.

          en plus comme son nom l'indique custom laisse supposé que certains points sont paramétrables, et donc le moteur de compression l'est probablement.

          • [^] # Re: pg_dump -Fp ?

            Posté par (page perso) . Évalué à 1 (+0/-0).

            Pour éviter les problèmes de brevet, globalement, la compression dans PostgreSQL n'est pas top et sera toujours moins bien que ce qui se fait de mieux en outil externe.

      • [^] # Re: pg_dump -Fp ?

        Posté par (page perso) . Évalué à 4 (+1/-0).

        Ça fait longtemps que je n'ai pas refait de postgresql… Mais avec mysqldump pipé dans bzip2 ou xz, la compression était plus lente, ralentissant le pipe, augmentant très nettement le temps de dump, et, dans MySQL, le verrouillage sur la ou les tables. Bref il valait mieux (pour les autres utilisateurs de la BD) dumper en gz, adapté à un flux et rapide, quitte à ensuite reconvertir du gz en xz. Après tout a peut-être évolué, vitesse des CPU, compression avec accélération matérielle et disque SSD, mais je ferais perso néanmoins une vérif sur ce point avant de passer en prod.

        • [^] # Re: pg_dump -Fp ?

          Posté par . Évalué à 1 (+0/-0).

          Salut,

          Merci pour cette remarque judicieuse, si j'en crois la doc de pg_dump
          pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers).

          Le temps de traitement ne semble pas être un problème dans la mesure où les utilisateurs ne sont pas bloqués.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.