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 Sébastien Maccagnoni (site web personnel) . Évalué à 4.
Salut,
Ce qui me fait très très peur, c'est ça :
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 paulez (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 Sébastien Maccagnoni (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 Sébastien Maccagnoni (site web personnel) . Évalué à 2.
Enfin, j'ajoute qu'il faut choisir :
(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 paulez (site web personnel) . Évalué à 3.
Le
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 jean_clume . É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 paulez (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 jean_clume . É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:
Ce qui me choque c'est controller type='ide' normal?
[^] # Re: Performance base de données
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 1.
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 Sébastien Maccagnoni (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 paulez (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 jean_clume . É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 Sébastien Maccagnoni (site web personnel) . Évalué à 1.
Il me semble que PostgreSQL offre de meilleures performances.
[^] # Re: Performance base de données
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 3.
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 !
[^] # Re: Performance base de données
Posté par jean_clume . Évalué à 1.
En attendant d'avoir des fonds pour investir dans du matériel je pense appliquer cette méthode pour refaire des tables "propres" et gagner un peu en espace disque:
http://phucnw.blogspot.fr/2014/11/cleaning-up-zabbix-database.html
La seule inconnue étant la durée de l'INSERT …
[^] # Re: Performance base de données
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 1.
Ça ne va pas apporter grand chose, le problème est au niveau des performances requises.
Que la base soit pleine ou vide, 100 millions de requêtes par jour ça reste 100 millions de requêtes par jour.
Ça va très vite re-gonfler pour re-poser problème.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.