L'objectif principal de ce site de blog est la performance dans un environnement SQL Server. On pourrait dire que la performance commence par la conception de la base de données et de l'application. Mais vous pouvez également faire valoir que la disponibilité des bonnes ressources est essentielle pour de bonnes performances. Malgré toutes les discussions sur les bonnes ressources (quel modèle de processeur, quelle quantité de mémoire, quel type de stockage), nous négligeons parfois l'acte de planification de la capacité :utiliser les données dont nous avons pour prendre des décisions éclairées sur ce dont nous avons besoin . La planification de la capacité ne consiste pas seulement à déterminer la quantité d'espace disque dont nous avons besoin, elle implique également les ressources dont une instance SQL Server doit disposer pour gérer la charge de travail.
Nouveau ou existant ?
La planification des capacités pour une nouvelle solution est vraiment délicate. Vous devez établir des estimations de la charge de travail en fonction des informations que vous collectez auprès de l'entreprise. Cela signifie que vous devez poser des questions difficiles sur la quantité de données attendues au cours du premier mois, des six premiers mois et de la première année. Lorsqu'une nouvelle solution arrive, c'est souvent la DERNIÈRE chose à laquelle l'entreprise pense, donc très souvent, vous obtiendrez des réponses vagues. Dans le cas d'une nouvelle solution, vous devez vraiment faire un effort de meilleure estimation. Ne vous arrachez pas les cheveux en essayant d'obtenir des chiffres exacts.
Si la solution provient d'un fournisseur, vous devez lui demander des recommandations de planification concernant à la fois l'espace nécessaire et les ressources nécessaires. J'admets qu'ils n'ont peut-être pas ces données, mais vous n'obtenez pas ce que vous ne demandez pas. Ça ne fait jamais de mal d'essayer.
[Bonus :Si le fournisseur n'a aucune information à fournir, ne serait-il pas utile, après que le système soit opérationnel pendant quelques mois, que vous lui envoyiez vos données... comme le matériel dont vous disposez , et à quoi ressemble la charge de travail ? Il n'est pas nécessaire qu'il s'agisse d'un article de 20 pages, mais les commentaires pourraient les inciter à être plus proactifs à l'avenir.]
En ce qui concerne une solution existante, si vous rencontrez un problème de performances ou si vous cherchez à mettre à niveau le matériel, vous souhaiterez capturer des informations sur l'environnement actuel afin d'en planifier un nouveau.
Stockage
Planification du montant de stockage nécessaire est assez simple, cela nécessite juste une certaine planification à l'avance. Dans mes articles proactifs sur la vérification de l'état de SQL Server, j'aborde la surveillance de l'espace disque et j'inclus une requête pour capturer les informations sur les fichiers. Cette requête capture la taille des fichiers de base de données pour l'instance ainsi que l'espace utilisé. Il est impératif de suivre la tendance de ces données au fil du temps, et cela ne signifie pas quelques semaines. Vous cherchez à voir comment les fichiers changent au fil des mois, peut-être jusqu'à un à deux ans, car les modèles d'utilisation d'une application peuvent changer. Ces informations sont faciles à capturer, nécessitent peu d'espace pour être stockées et sont d'une valeur inestimable à avoir comme référence lorsque vous achetez du stockage. Si vous pouvez fournir des données quantitatives sur la croissance du système, vous avez de bien meilleures chances d'obtenir l'espace dont vous avez besoin dès le départ plutôt que d'avoir à le demander plus tard. Et lorsque vous demandez de l'espace, assurez-vous d'inclure tempdb dans vos calculs.
Ressources matérielles
CPU
L'optimisation des performances de votre CPU ne concerne pas seulement le nombre de CPU dont vous disposez, vous devez également tenir compte du modèle et de la charge de travail (par exemple, entrepôt de données avec de grandes requêtes parallèles par rapport à OLTP avec des requêtes en série). Avec ces informations et un peu d'aide de Glenn, vous pouvez déterminer le meilleur processeur pour votre serveur. N'oubliez pas de prendre en compte les coûts de licence et les limitations en fonction de votre édition de SQL Server !
Mémoire
La mémoire est relativement peu coûteuse et nous vous recommandons de toujours acheter la quantité maximale de mémoire qu'un serveur peut contenir. La lecture de données à partir de la mémoire est nettement plus rapide que la lecture à partir du disque, donc plus il y a de données qui tiennent dans la mémoire, mieux c'est. Notez que l'ensemble de la base de données n'a pas pour tenir dans la mémoire. Vous avez juste besoin que l'ensemble de données de travail tienne dans la mémoire. Considérez une base de données de 2 To. Il est peu probable que, dans un scénario OLTP, tous les 2 To soient consultés chaque jour. En règle générale, seules les données récentes sont consultées - peut-être uniquement les 30 ou 60 derniers jours. Ce sont les données qui doivent tenir en mémoire. Mais bien sûr, nous voyons rarement un environnement OLTP pur, souvent c'est un environnement mixte parce que les utilisateurs aiment exécuter des rapports sur de grands ensembles de données, et il n'y a pas d'entrepôt de données ou de copie de rapport de la base de données donc ils ont pour exécuter les rapports par rapport à la production. Cela complique les besoins en mémoire. Maintenant, parfois vous avez besoin de ces données plus anciennes en mémoire, mais parfois ce n'est pas le cas. Il est important de comprendre la charge de travail; quels types de requêtes sont exécutées sur la base de données ?
Si vous utilisez Standard Edition, vérifiez que vous disposez de plus de mémoire sur le serveur que la mémoire maximale prise en charge. Par exemple, avec SQL Server 2014 et versions ultérieures, dans l'édition Standard, la quantité maximale de mémoire que vous pouvez allouer au pool de mémoire tampon (via le paramètre de mémoire maximale du serveur) est de 128 Go. Par conséquent, vous souhaitez disposer de plus de mémoire sur le serveur (par exemple, 160 Go) afin de pouvoir définir la mémoire maximale du serveur sur la valeur la plus élevée possible de 128 Go, tout en conservant de la mémoire disponible pour le système d'exploitation et les autres processus SQL Server. De plus, avec SQL Server 2016 SP1 Standard Edition, vous pouvez utiliser l'OLTP en mémoire, avec une limite de 32 Go par base de données. C'est au-dessus de la valeur maximale de la mémoire du serveur, donc si vous prévoyez d'utiliser cette fonctionnalité, achetez de la mémoire en conséquence.
Stockage
Lorsque nous parlons d'exigences de performances pour le stockage, vous entendez souvent parler d'IOPS (opérations d'entrée/sortie par seconde). En fait, cet article a été inspiré par une question d'un téléspectateur qui a regardé mon cours Pluralsight sur l'analyse comparative et la référence. La question était :"Comment corrélez-vous les compteurs de l'Analyseur de performances pour les lectures et les écritures par seconde aux connexions utilisateur pour estimer le nombre d'E/S par utilisateur ?" Les lectures et les écritures par seconde sont les opérations d'entrée/sortie, nous avons donc ces données disponibles via PerfMon au niveau de l'instance, et c'est ce que vous utilisez pour définir les exigences IOPS pour une instance.
Cependant, si vous savez lire et écrire et connexions utilisateur, vous pouvez alors faire des calculs et déterminer les IOPS par utilisateur. Ceci est utile si vous envisagez de développer la solution et d'ajouter plus d'utilisateurs. Vous voulez vous assurer que la solution évoluera, et une option que vous avez est de prendre vos IOPS calculées par utilisateur, en fonction du nombre X d'utilisateurs, puis d'estimer les IOPS de l'instance pour le nombre Y d'utilisateurs. Maintenant, nous faisons beaucoup d'hypothèses avec ce calcul. Nous supposons que la façon dont les nouvelles connexions utilisent le système est la même qu'aujourd'hui - cela peut ou non être le cas à la fin, vous ne le saurez pas tant que le système ne sera pas en place. Lorsque vous comprenez cette valeur (lectures + écritures / connexions utilisateur =IOPS moyen par utilisateur), vous savez alors comment estimer les IOPS pour une solution basée sur les connexions utilisateur anticipées.
Vous apportez ensuite ces informations à votre responsable du stockage pour discuter des configurations potentielles disponibles. Vous pouvez calculer l'IOPS maximum pour une configuration de disque, à condition d'avoir des informations sur les disques (par exemple, le nombre de disques, la vitesse, la taille et la configuration RAID). Vous pouvez tester le débit d'E/S d'un lecteur à l'aide de CrystalDiskMark, bien que cela ne soit pas possible si le stockage n'a pas été décidé. Cependant, une fois qu'il est en place, vous devez effectuer ces tests pour vous assurer que les IOPS d'un lecteur donné peuvent répondre à la charge de travail attendue.
Les IOPS ne sont qu'une façon d'examiner les performances de stockage. Comprenez que ces données vous indiquent la quantité d'E/S qui se produisent et, idéalement, si vous connaissez les IOPS et que vous disposez du stockage nécessaire pour répondre aux exigences, la latence doit être minimale. Mais c'est la latence qui affecte les performances. Afin de déterminer la latence existante, vous devrez utiliser un outil tel que DiskSpd pour comparer le stockage. Glenn a un excellent article qui explique comment analyser les performances d'E/S, puis un autre article sur la façon d'utiliser DiskSpd pour le tester afin de comprendre la latence. Je vous recommande vivement de consulter les deux articles si vous n'avez pas encore examiné le stockage et les performances.
Conclusion
La planification de la capacité ne se limite pas à savoir de combien d'espace vous avez besoin pour les fichiers de base de données. Vous devez comprendre la charge de travail et ses besoins en termes de ressources CPU, mémoire et disque. Pour ce faire, vous avez besoin de données… ce qui signifie que vous avez besoin de lignes de base de capture. Ma toute première session dans la communauté SQL Server a eu lieu en décembre 2010 et portait sur le thème des lignes de base. Six ans plus tard, je parle toujours de leur importance, et j'entends encore des gens dire qu'ils n'ont pas ces chiffres. Si vous souhaitez effectuer une planification de capacité intelligente et ciblée, vous devez collecter les données appropriées... sinon vous ne faites que deviner.
