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 Sébastien Maccagnoni . En réponse au message [Zabbix]: problème de performance serveur. É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à...)