Je ne suis pas expérimenté avec le travail DBA, mais j'essaie de faire un cas pour demander des ressources supplémentaires pour notre serveur SQL et espérais que je pourrais obtenir des gens intelligents pour fournir une estimation approximative approximative de ce que nous devrions exécuter. Je soupçonne que l'allocation des ressources que l'informatique a données à notre serveur SQL de production est faible.
Matériel et logiciel:
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
Disque dur pour les fichiers de base de données: 300 Go
Disque dur pour les sauvegardes: 150 Go
Disque dur pour les journaux: 100 Go
Application:
Nous avons 3 bases de données principales qui totalisent environ 170 Go de données, une base de données Reporting Services (SSRS) sur le même serveur qui héberge peut-être 10 rapports différents (comprenant en moyenne 700k enregistrements chacun) qui sont générés quotidiennement. Notre base d'utilisateurs est d'environ 20 utilisateurs simultanés, dont 5 pourraient être considérés comme «gourmands en ressources» avec la génération de rapports volumineux. 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. De plus, nos développeurs utilisent largement SSIS dans BIDS en se connectant directement sur le serveur (2 connexions distantes max). 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.
Problèmes actuels:
Nous avons des délais d'expiration de serveur chroniques et le temps de réponse au site Web est assez mauvais. Je soupçonne que la quantité de mémoire que nous avons (4 Go) est probablement un gros goulot d'étranglement. 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. Bien que nous ne soyons pas des pros SQL ou (comme je suis sûr que vous pouvez le dire par notre configuration), je suis sûr de ne pas perdre tout mon temps à essayer de réduire les performances potentielles si le matériel est le goulot.
Merci à tous pour le tl; dr évitement!
Réponses:
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.
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.
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.
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.
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.
la source
C'est la folie du «compteur de haricots». Les 1100 $ - 2500 $ que vous dépenseriez pour la RAM pourraient être remboursés en une semaine !
Ils obtiennent des congés pour 20 employés et 5 d'entre eux effectuent un travail «intensif en ressources». J'imagine que leur temps n'est pas bon marché, et certains de ces rapports sont ceux que le patron ne signant pas sur le salaire aimerait. C'est des tonnes de gaspillage gaspillé à retransmettre et à gérer la frustration.
Expliquez-leur qu'ils recherchent probablement entre 15 et 20 $ par Go de RAM. 128 Go de RAM coûteraient environ 2200 $ - 2500 $ en ce moment, et les prix de la RAM ont actuellement légèrement augmenté. Même si la carte mère de vos serveurs ne peut pas la prendre en charge (ce serait étrange), alors 64 Go seraient de 1100 $ à 1200 $ (je viens de vérifier, et c'est la qualité de la RAM du serveur de Dell sans aucune réduction appliquée). Même 64 Go de RAM pourraient faire une énorme différence (surtout si nous nous assurons d'éviter les analyses de table de grandes tables).
Calculez le temps perdu et demandez-leur s'il vaut entre 1 100 $ et 2 500 $. Si vous ne dépensez que 1100 $ et obtenez 64 Go de RAM, assurez-vous d'éviter les analyses de table sur les grandes tables. Utilisez plus de disque avec des index (si vous avez la latence pour le prendre en charge) pour éviter que les analyses volumineuses ne vident la mémoire.
la source
J'utilise 2008 R2 avec 46 Go de Ram. Pas de machines virtuelles. SQL Server 2008.
Les bases de données font environ 300 Go.
J'ai récemment mis les bases de données sur un disque SSD et triplé ma sortie de données.
Le serveur utilise actuellement 45 Go de Ram et fonctionne bien.
Raids FC Sata et SAS SCSI Raids. 26 disques logiques en tout. 144 Disques en rotation.
Hier, je n'utilisais que 24 Go de RAM alors que je n'avais que 50 To de disques durs complets connectés et transférant des données. Aujourd'hui, j'ai 160 To de disques durs complets et j'utilise 45 Go de RAM.
Mon application n'utilise pas plus de 400 Mo de RAM.
Je soupçonne que vous avez besoin des bases de données sur un disque SSD rapide ou un disque RAM. Fondamentalement, bien que vous ayez besoin de beaucoup plus de RAM.
la source