Serveur d'entrepôt de données. Comment calculez-vous les spécifications RAM / CPU?
J'essaie d'écrire une spécification pour un serveur d'entrepôt de données pour notre mise à niveau planifiée de l'entrepôt de données.
Comme nous exécutons des serveurs virtuels sur des hôtes VMWare, nous avons la possibilité d'ajouter ou de supprimer des ressources si nécessaire. Dans le passé, nous avons ajouté progressivement RAM et CPU selon les besoins. Comme nos demandes ont augmenté, nous avons fait pression pour plus de ressources (principalement disque et RAM).
Nous en redemandons. Ils nous en donnent le moins possible.
Cependant, récemment, chaque fois que nous parlons de ressources, nous sommes maintenant critiqués pour ne pas avoir spécifié la machine en premier lieu, et on me dit maintenant que les hôtes de développement sont au maximum, il n'y a plus RAM = disponible.
Nous sommes une petite organisation de gouvernement local avec environ 50 utilisateurs réguliers du DW. En utilisation quotidienne normale, il fonctionne bien. Nous obtenons de bonnes performances de requête mdx, et nos rapports et tableaux de bord sont rapides. Les utilisateurs sont contents.
Cependant, nos processus ETL fonctionnent toute la nuit et nous commençons à voir des preuves de la pression de la mémoire lors du traitement simultané des datamarts. Hier soir, SSIS a échoué avec des avertissements concernant une "erreur de mémoire insuffisante".
Notre serveur DW existant est Win 2008 R2 avec 4 CPU et 16 Go de RAM exécutant SQL 2012 Std. J'ai la mémoire maximale du serveur fixé à 12 Go, laissant 4 Go pour le système d'exploitation et les services, etc. Notre DW existant dispose de 3 cubes datamarts/OLAP, et nous développons 2 autres.
+----------+----------+---------------+-----------+---------------+
| Datamart | Files GB | Fact (Rows) | Fact (Mb) | ETL & Process |
| OLAP cube| | | | Time (hours) |
+----------+----------+---------------+-----------+---------------+
| PBI | 3 | 190,000 | 180 | 0.2 |
| FBI | 30 | 26,100,000 | 10,000 | 1.5 |
| RBI | 175 | 62,000,000 | 32,000 | 8.3 |
| ABI* | 100 | 44,050,000 | 21,000 | 4.0 |
| EBI* | 11 | 100,000,000 | 6,000 | 2.0 |
+----------+----------+---------------+-----------+---------------+
* Planned/Estimated
Notre nouveau serveur devrait être Win 2012 exécutant SQL 2016 Enterprise. Il exécutera SQL, SSIS, SSRS et SSAS. Le stockage n'est pas un problème, mais je ne suis pas sûr de RAM & CPU.
Selon le Guide de référence de l'entrepôt de données Fast Track pour SQL Server 2012 , le minimum que je devrais avoir est de 128 Go pour une machine à 2 sockets ... ce qui semble un peu excessif. Configuration matérielle et logicielle requise pour l'installation de SQL Server 2016 recommande un minimum de 4 Go de RAM pour SQL 2016. C'est toute une différence!
Alors .. Qu'est-ce qu'un bon point de départ? 32 Go? 64 Go? Comment puis-je justifier ma position de départ (spécification) auprès de l'informatique?
Existe-t-il de bons guides sur la façon de calculer les ressources du serveur?
Existe-t-il de bonnes règles générales?
Quels sont les ingrédients/mesures clés pour le dimensionnement RAM dans un contexte DW?
- Le volume de données?
- Le nombre de cubes?
- Le temps qu'il faut pour faire ETL ou traiter un cube?
- Charge de traitement maximale pendant la nuit ou performances telles que vues par les utilisateurs finaux pendant la journée?
Excellente question, et j'ai fait une session à ce sujet à TechEd il y a quelques années, intitulée Building the Fastest SQL Servers:
https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DBI328
Dans ce document, j'explique que pour les entrepôts de données, vous avez besoin d'un stockage qui peut fournir des données suffisamment rapidement pour que SQL Server les consomme. Microsoft a créé une grande série de livres blancs appelés Fast Track Data Warehouse Reference Architecture qui va dans les détails du matériel, mais l'idée de base est que votre stockage doit être en mesure de fournir des performances de lecture séquentielle de 200 à 300 Mo/s, par cœur de processeur, dans afin de garder les CPU occupés.
Le plus de vos données que vous pouvez mettre en mémoire cache, le stockage le plus lent avec lequel vous pouvez vous en sortir. Mais vous avez moins de mémoire que nécessaire pour mettre en cache les tables de faits avec lesquelles vous traitez, donc la vitesse de stockage devient très importante.
Voici vos prochaines étapes:
- Regardez cette vidéo
- Testez votre stockage avec CrystalDiskMark ( voici comment )
- Avec 4 cœurs, vous aurez besoin d'au moins 800 Mo/s de débit de lecture séquentiel
- Si vous ne l'avez pas, envisagez d'ajouter de la mémoire jusqu'à ce que la douleur disparaisse (et la mise en cache de la base de données entière dans RAM n'est pas impensable)
Supposons que vous disposez d'une base de données de 200 Go et que vous ne pouvez pas obtenir un débit de stockage suffisant pour occuper vos cœurs. Il n'est pas impensable d'avoir besoin non seulement de 200 Go de RAM, mais encore plus - car après tout, SSIS et SSAS veulent vraiment faire leur travail en mémoire, vous devez donc disposer des données du moteur, ainsi que d'un espace de travail pour SSIS et SSAS.
C'est aussi pourquoi les gens essaient de séparer SSIS et SSAS sur différentes machines virtuelles - ils ont tous besoin de mémoire simultanément.
Le Guide de référence de l'entrepôt de données Fast Track pour SQL Server 2012 est en fait un peu obsolète, surtout si vous passez à SQL Server 2016 (vraiment? Appelez-moi), pas seulement en termes de temps , mais aussi des fonctionnalités.
Dans SQL Server 2012, la version sur laquelle la procédure accélérée est basée, vous ne pouviez avoir que des index columnstore non groupés. Ce sont des structures distinctes de la table principale, ce qui entraîne des frais supplémentaires de stockage et de traitement en raison de copies compressées des données.
À partir de SQL Server 2014, vous pouvez avoir des index clusterstore groupés. Ceux-ci offrent une compression massive et une augmentation potentielle des performances pour les requêtes agrégées/récapitulatives. Ils sont tout à fait appropriés pour les tables de faits, donc votre table de faits de 32 Go pourrait ressembler davantage à ~ 8-12 Go. YMMV. Cela change légèrement le paysage, n'est-ce pas? En regardant votre table (et le pouce en l'air), vous pourriez peut-être vous en tirer avec 32 Go, mais je tirerais pour 64 Go (ce n'est pas comme si vous demandiez 1 To) et laissais une place pour d'autres services et la croissance, la justification étant que cela permet vous tenez votre plus grande table en mémoire, laissez de la place pour la croissance et de la place pour d'autres services . Vous n'avez pas besoin de leur parler de la compression. Une chose que vous devez garder à l'esprit avec le dimensionnement est que vous n'êtes pas seulement en train de dimensionner vos données maintenant, mais comment elles seront, disons dans un an. Notez également que les performances des recherches de points peuvent être horribles, mais lorsque vous passez à SQL Server 2016, vous pouvez ajouter des index supplémentaires ou vous pouvez toujours envisager Index de colonnes pour les analyses opérationnelles en temps réel bien que vous 'ai besoin de plus de mémoire pour cela:)
Comment allez-vous faire avec les CTP en passant, actuellement au CTP3.3, il a la plupart des fonctionnalités que vous voudrez peut-être utiliser, donc vous dites que vous n'avez pas de ressources pour les essais, mais vous pouvez obtenir un essai Windows Azure , faites tourner une machine virtuelle, créez gratuitement des exemples de données, testez la compression, les performances des fonctionnalités clés et des requêtes, etc. Ou si vous avez une licence MSDN, celle-ci est intégrée.
En résumé, taillez pour permettre à votre plus grande table d'être en mémoire (ainsi que d'autres choses) ou configurez un essai simple (gratuit dans le cloud) pour obtenir les preuves tangibles que vous recherchez. N'oubliez pas de désallouer votre VM lorsque vous avez terminé:)
Vraisemblablement, lors du développement et de la maintenance des packages ETL sur des machines de développement locales, vous utilisez parfois des données de test d'une échelle similaire ou plus grande que celle que vous attendez en production, et sinon, vous pourriez peut-être envisager de le faire (données réelles anonymisées ou données de test générées par algorithme, si vos données réelles sont sensibles).
Si tel est le cas, vous pouvez exécuter le processus dans diverses conditions de mémoire et le profiler, pour voir le point où plus RAM cesse de faire une énorme différence - aussi utile que les règles de base et rien de conjecture éduqué l'analyse comparative et le profilage peuvent fournir des réponses beaucoup plus concrètes et, en prime, peuvent mettre en évidence des goulots d'étranglement évidents qui pourraient être faciles à optimiser. Bien sûr, vos environnements de développement/test peuvent ne pas correspondre exactement à la production, vous devrez donc peut-être utiliser l'expérience pour interpréter la façon dont les résultats peut changer.
Si vous exécutez SSIS sur la même machine que les bases de données, vous devez absolument vous assurer que les instances du moteur SQL Server sont définies pour ne jamais réclamer toute la mémoire. Non seulement la privation de mémoire peut provoquer des erreurs MOO dans SSIS, mais bien avant cela, elle peut entraîner des problèmes de performances importants car elle spoule les tampons sur le disque alors qu'elle pourrait autrement les conserver dans la RAM. Le montant que vous devez réserver pour SSIS et d'autres tâches variera considérablement en fonction de votre processus.Le profilage est donc une bonne façon d'évaluer cela. Il est souvent recommandé d'exécuter SSIS sur une machine distincte pour faciliter la gestion, bien que vous puissiez avoir des problèmes de débit réseau et de licence à prendre en compte.
Mise à jour
Si, selon votre commentaire, aucune ressource n'est disponible pour effectuer des tests de performance réalistes pour évaluer où les performances diminuent (et/ou des erreurs OOM et des problèmes connexes commencent à se produire) si trop peu RAM is allouées, les choses deviennent beaucoup plus ondulantes sans une connaissance intime des processus d'entrepôt et ETL. Une règle de base pour la base de données d'entrepôt elle-même: vous en voulez assez RAM pour pouvoir contenir ensuite l'intégralité de tous les indices les plus couramment utilisés, puis certains pour permettre des données moins couramment utilisées et plus encore pour permettre la croissance attendue dans un avenir proche/moyen.
Le calcul peut être faf - sp_spaceUsed ne décompose pas les choses par index, vous devrez donc interroger directement sys.allocation_units et vos amis. Il existe cependant quelques exemples pour vous aider à démarrer, http://blog.sqlauthority.com/2010/05/09/sql-server-size-of-index-table-for-each-index -solution-2 / ressemble au meilleur des premiers issus d'une recherche rapide.
En plus des besoins pour exécuter la base de données d'entrepôt elle-même, n'oubliez pas d'ajouter les exigences RAM pour SSIS s'il doit s'exécuter sur la même machine et assurez-vous que SQL Server dispose de RAM limites en place pour garantir que cette mémoire est réellement disponible pour SSIS.
D'après les tailles de données globales que vous indiquez, mon instinct suggère que 32 Go serait le minimum absolu que je recommanderais uniquement pour le moteur de base de données et SSIS, définissant la ou les instances SQL à utiliser au maximum 26, et comme vous exécutez également SSRS et autres services sur la même machine, un minimum raisonnable avec une future vérification serait de 64 Go (les deux tiers de vos données actuelles devraient tenir en cela après que d'autres services et réservations aient leur coupe). Évidemment, citer mon instinct ne vous mènera pas très loin dans les discussions avec les gens de votre infrastructure ...