Forum Linux.général [Zabbix]: problème de performance serveur

Posté par  . Licence CC By‑SA.
Étiquettes :
0
21
août
2015

Bonjour,
je sais qu'il y'a quelques gros fans zabbix qui trainent ici, je poste donc dans l'espoir que quelqu'un puisse m'orienter sur ma configuration.

Le contexte: 1 VM Ubuntu server 12.04 4 VCPU, 12GB ram, 80GB disk zabbix 2.2.8 + Mysql sur un autre serveur
Concernant zabbix:

*Number of hosts: 5472
*Number of items: 320402
*Number of triggers: 238018
*Number of users: 29
*Requiered server performance: 1228.98

Au niveau de la configuration du /etc/zabbix/zabbix_server.conf voici ce qui diffère de la configuration par défaut:

NodeID=1
LogFile=/var/log/zabbix/zabbix_server.log
LogFileSize=0
DebugLevel=3
PidFile=/var/run/zabbix/zabbix_server.pid
DBHost=zabbix-db-1
DBName=zabbix
DBUser=zabbix
DBPassword='password'
DBSocket=/var/run/mysqld/mysqld.sock
StartTrappers=50
StartPingers=50
HousekeepingFrequency=4
CacheSize=256M
TrendCacheSize=512M
ValueCacheSize=512M
AlertScriptsPath=/usr/lib/zabbix/alertscripts
ExternalScripts=/usr/lib/zabbix/externalscripts
FpingLocation=/usr/bin/fping
Fping6Location=/usr/bin/fping6
LogSlowQueries=10000

La supervision est passive, ce sont les agents de mes nodes qui renvoient leur valeurs (d'où le nombre de trapper)

En surveillant les graphs de performance du serveur, je me rends compte que toutes les heures j'ai le zabbix busy history syncer processes qui montent à 100% pendant quelques minutes, pendant cette période le serveur n'arrive plus à tracer les autres graphes de supervision du serveur zabbix.

Dans les logs du serveur je vois que ces pics correspondent à l'insertion de valeurs dans la table history_uint du style:

**slow query: 11.011690 sec, "insert into history_uint (blablabla)**

ou des queries en erreurs du style:

** [Z3005] query failed: [1205] Lock wait timeout exceeded; try restarting transaction [update ids set nextid=nextid+1 where nodeid=1 and table_name='items' and field_name='itemid']**

Avez vous une piste à me conseiller concernant ce qui peut être fait (conf zabbix ou mysql)?

  • # Lourd !

    Posté par  (site web personnel) . Évalué à 4.

    Salut,

    Ce qui me fait très très peur, c'est ça :

    Requiered server performance: 1228.98

    Cela veut dire que ta machine doit recevoir 1229 (j'arrondis) valeurs par seconde.
    Donc presque 74000 nouveaux enregistrements par minute, ou encore plus de 4,4 millions par heure.
    Pour 320402 éléments, cela veut dire que ta "fréquence" moyenne de remontée d'infos est de 4 minutes. C'est court pour une fréquence globale, étant donnée la taille du parc.

    Et là, on ne parle que de l'enregistrement des nouvelles valeurs. Il faut aussi compter avec les tendances (que le serveur doit constamment calculer et insérer toutes les heures pour les valeurs qui "deviennent" plus anciennes) et avec les triggers à calculer (vraisemblablement, pour environ 66% des remontées d'infos).

    Il faut réduire la fréquence des remontées d'infos (donc augmenter l'intervalle entre deux remontées) pour les choses où il n'est pas nécessaire d'être aussi "réactif". Si tu peux aussi réduire le nombre de triggers, ce serait pas mal.

    Mais si tu as vraiment besoin d'une aussi grande réactivité et de tous ces triggers, il faudra améliorer les perfs de ta plateforme de supervision. Pour cela, plusieurs possibilités :
    - la première aurait été de séparer la base de données et le serveur Zabbix, mais ça tu l'as déjà fait
    - passer à PostgreSQL
    - mettre la base de données en cluster
    - ajouter des proxies
    - utiliser des machines plus puissantes

    Dans tous les cas, pense à te faire accompagner par un prestataire qui maîtrise bien Zabbix, au moins pour jeter un œil à ton infra et donner des conseils pertinent pour ton cas particulier (et pas seulement des généralités).
    Menfin les premiers conseils ce sera ce que je t'ai donné ci-dessus : réduire la fréquence (et hop, une presta de consulting en ligne gratuite). Avoir ton infra sous les yeux, ça permettra par exemple de te conseiller sur ce qu'il est pertinent de réduire.

    • [^] # Re: Lourd !

      Posté par  (site web personnel) . Évalué à 1.

      Je trouve ça dommage de réduire la fréquence de la supervision, je ne connais pas le besoin mais 4 minutes de latence minimum c'est déjà beaucoup dans certains cas.

      • [^] # Re: Lourd !

        Posté par  (site web personnel) . Évalué à 3.

        Oui mais non, là c'est une moyenne, sur l'ensemble des infos remontées.

        Est-il utile de remonter la taille totale de chacune des partitions toutes les 4 minutes ?
        Est-il utile de remonter l'uptime toutes les 4 minutes ?
        Est-il utile de remonter le hostname toutes les 4 minutes ?
        Pour toutes ces infos, la périodicité peut être montée à 1 heure, ce qui peut beaucoup faire augmenter la moyenne ;)

        Et l'espace libre sur le disque dur, par exemple, il n'est probablement pas nécessaire de le remonter toutes les minutes : toutes les 10 minutes ça peut être suffisant, voire toutes les demi-heures dans certains cas : là aussi on ferait augmenter la moyenne plutôt que la baisser.

        Bien sûr, certains indicateurs doivent être plus réactifs : le fait qu'un service web est en fonctionnement par exemple, toutes les minutes voire toutes les 30 secondes ça se justifie.

        • [^] # Re: Lourd !

          Posté par  (site web personnel) . Évalué à 2.

          Enfin, j'ajoute qu'il faut choisir :

          • soit on veut une supervision très fine et très réactive sur tout plein de points, auquel cas on met une base de données puissante ;
          • soit on veut garder un MySQL sur une VM, auquel cas il faut réduire les besoins de la supervision.

          (et il faudrait que je me calme un peu, là, sur 11 réponses j'en ai écrit 6…)

  • # Performance base de données

    Posté par  (site web personnel) . Évalué à 3.

    Le

    Lock wait timeout exceeded; try restarting transaction

    me fait penser que les requêtes en base prennent un peu trop de temps.

    Il faudrait que tu nous détailles la configuration de ton serveur de base de données pour voir ce qui peut être fait de ce côté là, étant donné qu'il semble être un goulot d'étranglement dans ton cas.

    • [^] # Re: Performance base de données

      Posté par  . Évalué à 1.

      Merci Sebastien et Paulez,
      effectivement c'est bien la base de donnée le goulot d'étranglement.

      Certaines tables sont assez volumineuses:
      12181516 kb history_str.ibd
      35266612 kb history_uint.ibd
      68874308 kb trends_uint.ibd
      119444604 kb history.ibd

      Je pense que la configuration Mysql a clairement été mal définie vu le besoin.
      Le serveur de bdd n'est pas sur la même VM , mais c'est une VM qui est … sur le même hyperviseur!
      Voici la configuration de la BDD:
      VM Ubuntu Server 12.04 6vcpu 16GB ram 300GB disk
      Le fichier /etc/mysql/my.cnf
      [client]
      port = 3306
      socket = /var/run/mysqld/mysqld.sock
      [mysqld_safe]
      socket = /var/run/mysqld/mysqld.sock
      nice = 0
      [mysqld]
      user = mysql
      pid-file = /var/run/mysqld/mysqld.pid
      socket = /var/run/mysqld/mysqld.sock
      port = 3306
      basedir = /usr
      datadir = /var/lib/mysql
      tmpdir = /tmp
      lc-messages-dir = /usr/share/mysql
      skip-external-locking
      key_buffer = 16M
      max_allowed_packet = 32M
      thread_stack = 192K
      thread_cache_size = 8
      myisam-recover = BACKUP
      query_cache_limit = 1M
      query_cache_size = 16M
      log_error = /var/log/mysql/error.log
      log_slow_queries = /var/log/mysql/mysql-slow.log
      long_query_time = 30
      server-id = 1
      log_bin = /var/log/mysql/mysql-bin.log
      expire_logs_days = 5
      max_binlog_size = 300M
      binlog_do_db = zabbix
      innodb_buffer_pool_size = 12G
      [mysqldump]
      quick
      quote-names
      max_allowed_packet = 1G
      [mysql]
      [isamchk]
      key_buffer = 16M
       !includedir /etc/mysql/conf.d

      /run (/et var/run qui est en fait un lien) est en tmpfs et fait 3GB

      Apparemment il est conseillé de partitionner les tables les plus grosses (faisables avec MysqL?)
      Si réduire la fréquence des checks semble difficile je pense que je peux par contre réduire la durée de rétention des items si ça peut augmenter les performances.

      • [^] # Re: Performance base de données

        Posté par  (site web personnel) . Évalué à 2.

        Étant donné que ton MySQL tourne sur une VM, et que de nombreuses insertions vont surtout solliciter le sous-système de stockage, il faut essayer de voir s'il n'y a pas de gains faciles de ce côté là.
        Sur quel type de périphérique se trouve le stockage de la VM ? Utilise-tu VirtIo comme pilote pour la VM ?

        • [^] # Re: Performance base de données

          Posté par  . Évalué à 1. Dernière modification le 22 août 2015 à 11:45.

          Les VM sont chacune sur un LV LVM elles utilisent virtio.
          Par contre il y'a quelque chose de bizarre dans la configuration:

              # virsh edit zabbix-db-1


    <domain type='kvm'>
      <name>zabbix-db-1</name>
      <uuid>xxxxx-xxxxx-xxxxx-xxxxx</uuid>
      <memory>16777216</memory>
      <currentMemory>16777216</currentMemory>
      <vcpu>6</vcpu>
      <os>
        <type arch='x86_64' machine='pc-1.0'>hvm</type>
        <boot dev='hd'/>
      </os>
      <features>
        <acpi/>
      </features>
      <clock offset='utc'/>
      <on_poweroff>destroy</on_poweroff>
      <on_reboot>restart</on_reboot>
      <on_crash>destroy</on_crash>
      <devices>
        <emulator>/usr/bin/kvm</emulator>
        <disk type='file' device='disk'>
          <driver name='qemu' type='raw'/>
          <source file='/dev/kvm-6-vg/zabbix-db-1'/>
          <target dev='vda' bus='virtio'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
        </disk>
        <controller type='ide' index='0'>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
        </controller>
        <interface type='bridge'>
          <mac address='x:x:x:x'/>
          <source bridge='br0'/>
          <model type='virtio'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
        </interface>
        <input type='mouse' bus='ps2'/>
        <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'>
          <listen type='address' address='127.0.0.1'/>
        </graphics>
        <video>
          <model type='cirrus' vram='9216' heads='1'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
        </video>
        <memballoon model='virtio'>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
        </memballoon>
      </devices>
    </domain>

          Ce qui me choque c'est controller type='ide' normal?

          • [^] # Re: Performance base de données

            Posté par  (site web personnel) . Évalué à 1.

            Ce qui me choque c'est controller type='ide' normal?

            Je ne suis pas un méga-expert en VM, mais ça ne me semble pas choquant : si ça émule quelque chose, autant que ça émule quelque chose de simple…

          • [^] # Re: Performance base de données

            Posté par  (site web personnel) . Évalué à 2. Dernière modification le 22 août 2015 à 11:12.

            J'ajoute encore une remarque concernant la taille de la base de données :
            - avec une conservation de 7 jours et un tel nombre de données remontées, l'historique nécessitera environ 34 Go (bien sûr, une conservation de 30 jours demanderait presque 150 Go ;
            - les données de tendances, quant à elles, représenteront environ 334 Go sur un an ;
            - les événements, quant à eux, sont plus difficiles à quantifier. Prenons un scénario qui très très pessimiste de 1 événement par seconde ; cela représente alors environ 4 Go.

            Étant donnée la taille de ta supervision, on peut raisonnablement penser que ta base de données pèsera, une fois en prod depuis plus d'un an, environ 400 Go ; elle devra également être capable de gérer environ 2000 requêtes d'insertion par seconde.

            Une VM avec 16 Go de RAM et 300 Go de disque dur me semble insuffisante pour de telles perfs.
            D'où mon conseil de diminuer les demandes.

            Ou alors tu peux mettre un stockage attaché et exploité en "bas niveau" par la VM avec attachement PCI par exemple. Ou alors un SAN. Enfin voilà, un vrai truc performant, quoi.

            Je vais exprimer la chose autrement : tu as mis en place une infra qui impose au serveur MySQL d'encaisser plus de 100 millions de requêtes d'insertion par jour, ce uniquement pour les nouvelles données. En ajoutant les tendances, les événements et toutes les autres infos qui sont modifiées dans la base, à vue de nez je dirais que ça représente 150 ou 200 millions de requêtes par jour. C'est énorme, vraiment.

            (et faudrait vraiment que je donne moins de détails sur les forums, je suis en train de torpiller mon business model, là…)

          • [^] # Re: Performance base de données

            Posté par  (site web personnel) . Évalué à 2.

            T'es bien en virtio à priori pour le disque. Quel type physique de périphérique bloc utilise-tu ? Un ssd aide grandement par sa grande capacité en entrée/sorties pour pouvoir effectuer un plus grand nombre d'insertions dans la base.

            • [^] # Re: Performance base de données

              Posté par  . Évalué à 1.

              Merci des conseils.
              L'hyperviseur est un PowerEdge R420 avec des disques SCSI 15M trs/mns en raid1.
              Il y'a du LVM dessus et j'ai un LV pour chaque VM Zabbix et Zabbix-db.
              J'hérite de l'infra et il est clair que ce qui a été mis en place n'est pas dimensionné.
              Je pense que je peux investir dans du métal pour y coller mon zabbix-db, mais quid de la configuration (très peu de tuning mis en place finalement par rapport à un conf d'origine que ça soit au niveau Zabbix ou Mysql).
              Que pensez vous du fait de partitionner les tables ? Faut il une version de mysql spécifique pour ça (j'ai la 5.5.41) ou comme le disait Sebastien passer à Postgresql (c'était pour le partitionnement ou y'a t'il d'autres raisons?)

        • [^] # Re: Performance base de données

          Posté par  (site web personnel) . Évalué à 3.

          Étant donné que ton MySQL tourne sur une VM

          Cela ne me semblait pas évident à premier abord, vu qu'il avait écrit « Mysql sur un autre serveur »  ; au contraire j'avais cru que la base était sur une machine physique, avec cette formulation :)
          Il est bien sûr préférable d'avoir la base de données sur un serveur physique !

Suivre le flux des commentaires

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