... espérais pouvoir obtenir ... une estimation approximative de ce que nous devrions exécuter.
Sans plus d'informations sur vos requêtes et la taille des données, il est vraiment difficile de vous donner un type d'estimation, sans parler d'une estimation précise.
Base de données: SQL Server 2008 R2 Enterprise Database
Windows: Windows 2008 R2 Enterprise 64 bits, fonctionnant à peu près sur VMware.
Processeur: Intel (R) Xeon (R) CPU E7-4860 à 2,27 GHz 2,26 GHz (2 processeurs)
Mémoire installée: 4 Go
Deux processeurs (je suppose que cela est exposé dans la machine virtuelle en tant que 2 cœurs) peuvent ou non être sous-provisionnés. Les cœurs attribués à une machine virtuelle ne sont pas nécessairement mappés directement sur des cœurs physiques (ou même autorisés à utiliser 100% d'un seul cœur lorsque cela est nécessaire!), Vous pouvez donc trouver que c'est une ressource plus flexible que la mémoire. Sans plus d'informations sur votre charge de travail ou votre configuration matérielle / de virtualisation, je dirais que l'augmentation à 4 serait une bonne chose.
Allocation de mémoire. Oh mec. Ceci est largement sous-provisionné pour la charge de travail. Windows lui-même a besoin d'un minimum de 2-3 Go pour rester heureux, et chacun des 2 utilisateurs exécutant BIDS sur la boîte aura besoin d'au moins 500 Mo chacun. Et avec cela, la boîte est déjà au maximum, et je n'ai même pas commencé à déterminer de combien la base de données va avoir besoin.
La majorité des utilisateurs interagissent avec la base de données via le site Web asp.net et le site Web du serveur de rapports.
Vous ne l'avez pas dit, mais si ceux-ci fonctionnent sur la même boîte, les besoins en mémoire pour eux doivent également être pris en compte.
Enfin, nous avons une opération d'entreposage de données assez complexe qui génère probablement 3 millions d'enregistrements par jour via des packages SSIS qui s'exécutent également sur le serveur.
En supposant que cela fonctionne la nuit quand il n'y a pas d'utilisateurs en direct sur le système, je ne vois pas cela comme un problème à moins que cela ne prenne trop de temps à fonctionner. Cette partie des choses est le moindre de vos soucis; les utilisateurs en direct sont plus importants.
Nos demandes précédentes de mémoire supplémentaire ont été refusées avec la réponse commune dont nous avons besoin pour effectuer plus d'optimisations de requête.
Comme je l'ai démontré ci-dessus, la quantité de mémoire actuellement provisionnée est complètement insuffisante. Dans le même temps, cependant, à l'autre bout du spectre, il est extrêmement improbable que vous puissiez obtenir suffisamment de mémoire provisionnée pour pouvoir conserver la base de données entière en mémoire à la fois.
Même si vous avez obtenu une réponse globale comme celle-ci (qui, soit dit en passant, avait probablement plus à voir avec le degré de persuasion de votre justification pour des ressources supplémentaires, et non avec l' utilisation réelle des ressources elle-même), il est fort probable que l'efficacité de la base de données soit amélioré. Pourtant, aucun réglage ne peut à lui seul résoudre les problèmes que vous rencontrez actuellement; la suggestion de cela est un non-démarrage complet pour moi.
J'adopterais l'approche globale selon laquelle la quantité de mémoire actuellement provisionnée est inférieure au minimum requis (qui devrait être corrigé dès que possible), et des ressources supplémentaires peuvent être nécessaires pour améliorer l'expérience utilisateur à un niveau utilisable tandis que des améliorations sont apportées pour augmenter l'efficacité de les systèmes.
Voici quelques réflexions (par ordre d'attaque):
Vous gagnerez si vous pouvez prouver à quel point les performances s'améliorent à chaque fois que vous obtenez davantage de ressources. Gardez une trace des mesures de performances à l'aide de la journalisation de l'Analyseur de performances (remarque: la partie journalisation est très importante), y compris les temps de réponse du site Web si vous le pouvez. Commencez à le faire maintenant , avant de faire quoi que ce soit d'autre. Lorsque vous atteignez enfin la quantité minimale de mémoire (vous n'obtiendrez pas tout de suite 32 Go), tout à coup, vous avez maintenant la preuve que la mémoire ajoutée a amélioré les choses ... ce qui signifie que l'ajout de plus serait probablement utile aussi! Si vous ne collectez pas de référence sur la configuration actuelle, vous allez manquer le bateau lorsque les choses sont remontées au niveau minimum recommandé.
Analysez les statistiques d'attente de votre serveur . Cela vous dira quel est le plus gros goulot d'étranglement du système. Vous aurez probablement PAGEIOLATCH_XXle temps d'attente le plus courant / le plus élevé, ce qui indique que trop d'E / S sont en cours pour extraire des pages du disque. Cela peut être atténué en ajoutant de la mémoire, de sorte que les E / S physiques deviennent moins fréquentes car les données nécessaires sont déjà en mémoire. Bien que cette analyse soit à peu près perdue, le fait que vous ayez rassemblé ces statistiques vous donne plus de munitions pour justifier le besoin de ressources.
Comme je l'ai mentionné ci-dessus, le strict minimum de mémoire n'est pas respecté. Collectez l'ensemble des exigences matérielles recommandées pour tous les logiciels que vous exécutez, et peut-être également des captures d'écran du Gestionnaire des tâches. Cela seul devrait suffire à justifier au moins 4 à 8 Go de plus, sur place. S'ils refusent toujours, essayez de les convaincre de vous permettre de l'essayer pendant une semaine, et de le restituer après cela (vous collectez des statistiques de performance, vous n'aurez donc pas besoin de le rendre car en milieu de semaine, vous '' Je serai en mesure de prouver combien cela a amélioré la situation). S'ils refusent toujours , vous êtes prêt à échouer; URLT .
Si vous pouvez décharger une partie de la charge de travail (en particulier, évitez de vous connecter à distance si possible), cela augmentera la quantité de mémoire disponible pour la base de données, ce qui est plus critique.
Vous ne pourrez pas mettre la base de données entière en mémoire à la fois, ce qui signifie que vous devez définir le paramètre de mémoire maximale de SQL Server très soigneusement pour éviter une surcharge de la mémoire , ce qui tue les performances comme rien d'autre . La sur-validation est en fait encore pire que le simple fait de ne pas pouvoir tenir toutes les données en mémoire. Il est fort probable que vous vous trouviez dans ce scénario en ce moment simplement parce qu'il n'y a tout simplement pas de mémoire disponible du tout, et il est probable que le paramètre de mémoire maximale est défini par défaut (illimité).
Étant donné que vous exécutez SQL Server Enterprise Edition et que la mémoire est un atout, j'envisage fortement d'implémenter la compression des données . Cela compensera une augmentation de l'utilisation du processeur pour des économies d'espace de la mémoire (et donc des accès au disque réduits, qui sont comparativement très lents).
Réglez la base de données. Il est probable que les structures et les requêtes pourraient utiliser des améliorations en ce qui concerne les modèles d'indexation et d'accès. De plus, si de nombreuses données sont fréquemment analysées et agrégées, la création de vues indexées, de tableaux récapitulatifs ou de rapports précalculés peut être très utile.
Cela peut être long car cela signifie probablement plus de provisionnement matériel, mais implémentez une solution de mise en cache. La requête la plus rapide est celle que vous ne faites jamais .
Ce ne sont que quelques idées. L'essentiel est que le réglage à lui seul ne résoudra pas les problèmes ici, ni le matériel seul, même si ce dernier atténuera probablement la majorité des problèmes immédiats. C'est vraiment comme ça que ça se passe: jeter le matériel sur le problème à court terme pour éteindre le feu, et jeter le réglage sur le problème à long terme pour résoudre la cause première du mieux que vous pouvez.