Comment effectuez-vous le test de chargement et la planification de capacité pour les bases de données?

Il s'agit d'une question canonique sur la planification des capacités pour les bases de données.

En relation:

  • Pouvez-vous m'aider dans ma planification de la capacité?
  • Comment faites-vous le test de charge et la planification de la capacité pour les sites Web?

Je cherche à créer une question canonique sur les outils et les méthodes de planification des capacités pour les bases de données. Ceci est destiné à être une question canonique.

De toute évidence, le flux de travail général est:

  • Mettez votre scénario en place
  • Ajouter un suivi
  • Ajouter le trafic
  • Évaluer les résultats
  • Remédier en fonction des résultats
  • Rincer, répéter jusqu'à ce que raisonnablement heureux

N'hésitez pas à décrire différents outils et techniques pour différents serveurs Web, frameworks, etc., ainsi que les meilleures pratiques.

    2 Solutions collect form web for “Comment effectuez-vous le test de chargement et la planification de capacité pour les bases de données?”

    Planification de la capacité de disque et de RAM

    La planification du disque et de la capacité de la mémoire pour un serveur de base de données est un art noir. Plus c'est mieux. Plus vite est mieux.

    Comme lignes directrices générales, j'offre ce qui suit:

    • Vous voulez plus d'espace disque que vous en aurez jamais besoin.
      Prenez votre meilleure estimation de la quantité d'espace disque dont vous aurez besoin pour les 3 à 5 prochaines années, puis doublez-le.
    • Vous voudrez une RAM suffisante pour contenir vos index de base de données en mémoire, gérer votre plus grande requête au moins deux fois et avoir encore suffisamment de place pour un cache de disque OS sain.
      La taille de l'index dépend de votre base de données, et tout le reste dépend fortement de votre ensemble de données et de la structure de la requête / base de données. J'offrirai "au moins 2 fois la taille de votre plus grande table" comme une suggestion, mais notez que cette suggestion se décompose sur des opérations d'entreposage de données très importantes où la plus grande table peut être des dizaines ou des centaines de gigaoctets.

    Chaque fournisseur de base de données a des instructions sur le réglage de performance de votre noyau de disque / mémoire / OS: Passez du temps avec cette documentation avant le déploiement. Ça aidera.


    Bilan de charge de travail et planification de la capacité

    En supposant que vous ne l'avez pas encore déployé …

    De nombreux systèmes de bases de données sont livrés avec des outils de benchmarking – Par exemple, PostgreSQL est livré avec pgBench .
    Ces outils devraient être votre premier arrêt dans la performance de la base de données de benchmarking. Si possible, vous devriez les exécuter sur tous les nouveaux serveurs de base de données pour avoir une idée de «combien de travail» le serveur de base de données peut faire.

    Armé maintenant avec un point de repère brut qui est ABSOLUTELY MEANINGLESS , considérons une approche plus réaliste de l'analyse comparative: Chargez votre schéma de base de données et écrivez un programme qui le remplit avec des données fictives, puis exécutez les requêtes de votre application contre ces données.
    Cette référence marque trois éléments importants: 1. Le serveur de la base de données (matériel) 2. Le serveur de la base de données (logiciel) 3. La conception de votre base de données et sa manière d'interagir avec (1) et (2) ci-dessus.

    Notez que cela nécessite beaucoup plus d'efforts que les benchmarks simples pré-construits comme pgBench : vous devez écrire un code pour faire le peuplement et vous devrez peut-être écrire un code pour effectuer les requêtes et signaler l'heure d'exécution.
    Ce type de test est également beaucoup plus précis: puisque vous travaillez avec votre schéma et vos requêtes, vous pouvez voir comment ils fonctionneront et cela vous offre la possibilité de profiler et d'améliorer votre base de données / requêtes.

    Les résultats de ces repères sont une vue idéalisée de votre base de données. Pour être sûr, supposons que vous ne réaliserez que 50 à 70% de cette performance dans votre environnement de production (le reste étant un coussin qui vous permettra de gérer une croissance inattendue, des pannes matérielles, des changements de charge de travail, etc.).


    C'est trop tard! C'est en production!

    Une fois que vos systèmes sont en production, il est vraiment trop tard pour "benchmark" – Vous pouvez activer brièvement la journalisation / synchronisation des requêtes et voir combien de temps faut-il pour exécuter, et vous pouvez exécuter des requêtes sur le test de stress contre de grands ensembles de données pendant la mise hors service heures. Vous pouvez également consulter l'utilisation de la CPU, de la RAM et de l'E / S du système (bande passante du disque) pour avoir une idée de la densité de son chargement.
    Malheureusement, toutes ces choses vont vous donner une idée de ce que le système fait et un concept vague de la proximité de la saturation.
    Cela nous amène à …


    Suivi en cours

    Tous les points de repère dans le monde ne vous aideront pas si votre système voit soudainement des modèles d'utilisation nouveaux / différents.
    Pour le meilleur ou le pire, les déploiements de bases de données ne sont pas statiques: vos développeurs vont changer les choses, votre ensemble de données augmentera (ils ne semblent jamais se rétrécir) et vos utilisateurs créeront en quelque sorte des combinaisons insensées d'événements que vous n'avez jamais prédites dans les tests.

    Afin de faire une planification de capacité adéquate pour votre base de données, vous devrez mettre en place une sorte de surveillance de performance pour vous avertir lorsque les performances de la base de données ne répond plus à vos attentes. À ce stade, vous pouvez envisager des actions correctives (nouveau matériel, schéma DB ou modifications de requêtes pour optimiser l'utilisation des ressources, etc.).


    Remarque: Il s'agit d'un guide très généreux et générique pour dimensionner le matériel de votre base de données et déterminer la quantité d'abus qu'il peut prendre. Si vous ne savez toujours pas comment déterminer si un système spécifique répond à vos besoins, vous devez parler à un expert en base de données.
    Il existe également un site Stack Exchange spécialement dédié à la gestion de base de données: dba.stackexchange.com . Recherchez leurs archives de questions ou parcourez les étiquettes spécifiques à votre moteur de base de données pour d'autres conseils sur le réglage des performances.

    Généralement, vous avez besoin de cas d'utilisation réalistes pour tester les performances. La meilleure pratique consiste à impliquer les développeurs d'applications et les utilisateurs finaux.

    Notez ce qu'ils font généralement, paramétrer (contenu, nombre d'actions simultanées) pour chaque cas d'utilisation.

    Ensuite, créez le côté client. Une seule machine physique n'est souvent pas suffisante pour accumuler une charge de production.

    Ensuite, éteignez-le, étaler, améliorer et tester à nouveau.

    Vous serez surpris lorsque les bottlnecks augmentent.

    Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de réseau.