Skip to content
  • Categories
  • Recent
  • Popular
Collapse
Brand Logo
  1. Home
  2. Categories
  3. Sujets Techniques
  4. Optimisation et nettoyage des bases PostgreSQL

Optimisation et nettoyage des bases PostgreSQL

Scheduled Pinned Locked Moved Sujets Techniques
4 Posts 2 Posters 230 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    Axel P.
    wrote on last edited by Axel P.
    #1

    Bonjour,

    au fil des années les bases de données se remplissent petit à petit.

    Hors je remarque que la fonction "auto vacuum" n'est pas enclenchée dans le configuration de PostgreSQL.

    Voici la documentation officiel sur le sujet.

    Au vu des fonctionnements de PostgreSQL, je pense qu'il serait intéressant, pour éviter de trop gonfler, de ne pas laisser le système faire son nettoyage par lui même.

    En effet, il serait bon de paramétrer cette partie car par défaut l'analyse et le nettoyage se déclenche quand il y a à minima 50 lignes dans une table + 10% de lignes mises à jours, ajoutées, supprimées.
    Tout est bien lorsque la BDD est petite, mais au fil de l'eau il faudra de plus en plus de modifications sur une table de la BDD pour lancer le nettoyage.
    Au bout de quelques années (où d'un grand volume) le nettoyage ne se fait quasiment plus.
    Voici un explicatif en anglais.

    Il est plus intéressant de fixer un nombre fixe pour lancer ce nettoyage par exemple un scale à 0 et un treshold à 1000.

    Dans tous les cas, plus on attends, plus les performances se dégraderont, sans parler de l'espace qui demandera une marge d'espace inoccupé de plus en plus important.

    Voici les paramètres changeables :

    #------------------------------------------------------------------------------

    AUTOVACUUM PARAMETERS

    #------------------------------------------------------------------------------

    #autovacuum = on # Enable autovacuum subprocess? 'on'
    # requires track_counts to also be on.
    #log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
    # their durations, > 0 logs only
    # actions running at least this number
    # of milliseconds.
    #autovacuum_max_workers = 3 # max number of autovacuum subprocesses
    # (change requires restart)
    #autovacuum_naptime = 1min # time between autovacuum runs
    #autovacuum_vacuum_threshold = 50 # min number of row updates before
    # vacuum
    #autovacuum_analyze_threshold = 50 # min number of row updates before
    # analyze
    #autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum
    #autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze
    #autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum
    # (change requires restart)
    #autovacuum_multixact_freeze_max_age = 400000000 # maximum multixact age
    # before forced vacuum
    # (change requires restart)
    #autovacuum_vacuum_cost_delay = 20ms # default vacuum cost delay for
    # autovacuum, in milliseconds;
    # -1 means use vacuum_cost_delay
    #autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
    # autovacuum, -1 means use
    # vacuum_cost_limit

    Bonne journée

    Axel, Le Mans Université

    1 Reply Last reply
    1
    • B Offline
      B Offline
      bcrestani
      ADMIN SUPPORT-PROD
      wrote on last edited by
      #2

      Bonjour,

      La configuration autovacuum de PostgreSQL est correctement activée sur les instances GoFAST (activée par défaut par PostgreSQL).

      Cependant, la configuration utilise les paramètres par défaut, c'est-à-dire un scale factor à 0.2 (20 %) et un minimum de 50 lignes.
      En effet, comme vous l'avez souligné : "Au bout de quelques années (ou d'un grand volume), le nettoyage ne se fait pratiquement plus." en raison de la condition basée sur le pourcentage.

      Je vais ouvrir un ticket en interne afin que nous réexaminions cette configuration. Cela prendra du temps, car nous devrons effectuer de nombreux tests et benchmarks avant de pouvoir déployer la configuration à grande échelle.

      Je vous remercie pour votre suggestion,
      Benjamin

      1 Reply Last reply
      1
      • A Offline
        A Offline
        Axel P.
        wrote on last edited by
        #3

        Bonjour,
        certains acteurs du cloud conseillent 1000 comme valeurs fixes et disable le scale factor.

        Peut-être commencer vos tests avec ces valeurs.
        Si vous voulez nous pouvons tester sur notre preprod ensemble après une copie de la production (pour avoir un volume conséquent).

        Il faudra faire un nettoyage manuel avant de lancer cette configuration pour pouvoir évaluer le temps que cela prends sur un même volumes de changement et la même périodicité.

        Bonne journée

        Axel, Le mans Université

        1 Reply Last reply
        0
        • B Offline
          B Offline
          bcrestani
          ADMIN SUPPORT-PROD
          wrote on last edited by
          #4

          Bonjour,

          Nous prenons note de la possibilité de tester sur l'un de vos environnements, en plus de nos tests sur nos environnements d'intégration.
          J'ajoute cette information à notre ticket interne, et lors de son traitement, si nécessaire, l'équipe en charge reviendra vers vous !

          Merci pour votre proposition,
          Bonne journée,
          Benjamin

          1 Reply Last reply
          1
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Search
          • First post
            Last post
          0
          • Categories
          • Recent
          • Popular
          • Search