Announcement

Collapse
No announcement yet.

Problème taille/purge base de donnée

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problème taille/purge base de donnée

    Bonjour,

    Nous avons installé en février 2016 la version 2.7 de centreon "from scratch". Nous avons en tout 5 serveurs ( 3 pollers, 1 central pour le web et le broker et un serveur de BD).
    Nous avons environ 4000 hôtes et plus de 20000 services testés et la table data_bin fait 250Go. Par défaut cette table est créée en innodb et je pense que celle-ci est provisionnée de base.
    Le soucis c'est lors de la purge, aujourd'hui dès que celle-ci ce lance, le serveur de BD est plombé et répond très mal voir bloque totalement la remontée des pollers. La seule solution possible c'est de couper le broker et de laissé tourner la base pendant un certain temps tout seul afin qu'il vide son cache (ce que je présume), mais ça peut prendre jusqu'à 10h...
    Je ne sais pas comment on pourrait optimiser notre base de donnée ou si notre config n'est pas bonne.
    Voici notre config pour mariadb (celle par defaut dans CES 3.3) :

    [mysqld]
    datadir=/data/mysql
    max_connections= 250
    tmp_table_size = 24M
    max_heap_table_size = 24M
    query_cache_size = 256M
    key_buffer=256M
    key_buffer_size = 8182M
    thread_cache_size = 4
    table_cache = 500
    table_open_cache = 512
    slow_query_log
    local-infile=0
    max_allowed_packet = 32M
    innodb_file_per_table=1
    #log = /var/log/mysqld.log
    #log-error = /var/log/mysqld.error.log
    slow-query-log = 1
    slow-query-log-file = /var/log/mysqld-slow.log
    innodb_buffer_pool_size = 10G
    join_buffer_size = 10G
    innodb_buffer_pool_instances = 3
    sort_buffer_size = 20M
    read_rnd_buffer_size = 20M

    Merci de votre aide,
    Cordialement,

  • #2
    Bonjour,

    Nous avons le même soucis chez nous (data_bin de 80Go, logs de 200Go). Je constate en faisant un "show processlist", que la requête n'a pas de LIMIT. Une bonne technique serait de mettre un LIMIT raisonnable dans la query, afin que la transaction soit COMMIT beaucoup plus rapidement,et faire tourner le purge plus fréquemment.

    qui fait une demande change auprès des devs ?

    (chez nous, la purge a pas été faite depuis 6 mois, la transaction dure depuis 3 jours ...)

    Comment


    • #3
      J'ai eu le même soucis,

      j'ai désactivé la purge (cron de centstorage) pour le moment

      Je pense que le soucis vient du fait qu'il n'y ait pas d'index sur la date, ce qui fait qu'il a besoin d'un full table scan à chaque fois.

      Je pense à soit créer un index,
      mais dans ce cas downtime obligé (et assez long) car centreon écris tellement souvent dans cette table que ça génère des deadlock quand la db essaye de créer la liste.
      deplus la taille de l'index ne serait pas négligeable.
      Soit partitionner la table par mois et faire un drop partition en début de mois
      la purge serait instantanée mais
      il faut renommer la table
      recréer la table mais vide
      partitionner la table vide
      faire un méchanisme de stored procédure + trigger on delete pour vider l'ancienne table vers la nouvelle et récupérer l'historique

      Quelqu'un à t il essayé une manip du genre ?
      Ou un conseil à donner sur le sujet ??

      Comment


      • #4
        Effectivement nous avons fait la même chose, on a désactivé la purge, mais la base augmente assez vite du coup, on coupe pendant une journée pour faire cette purge...
        Pas vraiment tolérable sur la longueur. On envisage le partitionnement, mais comme il faut purger la table et potentiellement perdre l'historique, on est en attente de centreon 2.8 pour refaire une installation from scratch. Il semblerait que la version 2.8 intègre directement le partitionnement dans la base de donnée.
        On va aussi regarder comment prendre du support chez centreon, car le forum à quand même ça limitation :/

        Comment

        Working...
        X