Nous avons actuellement une machine virtuelle très sous-alimentée et proposons de passer à une machine virtuelle Azure avec de meilleures spécifications. Le problème est que la machine virtuelle Azure est beaucoup plus lente que la machine virtuelle d'origine, même si elle est d'une spécification plus élevée.
Le serveur d'origine est une machine virtuelle à 2 cœurs avec 2 Go de mémoire qui est également un serveur Web. Il est en cours d' exécution Web Edition Microsoft SQL Server 2008 R2 et parce que ce serveur est utilisé pour d' autres choses, nous avons dû limiter la mémoire de serveur maximale dans SQL Server à 512Mo .
Le nouveau serveur est une machine virtuelle 4 cœurs avec 7 Go de mémoire qui n'est qu'un serveur de base de données. Il exécute Microsoft SQL Server Standard Edition 2008 R2 et nous n'avons pas limité la quantité de mémoire que SQL Server peut utiliser.
Il s'agit de l'un des deux serveurs installés dans un environnement en miroir, mais la base de données sur laquelle j'exécute les tests n'est pas en miroir. Les autres bases de données sur ce serveur ne reçoivent pas beaucoup de trafic pour le moment (en fait, le moniteur d'activité ne montre aucune activité sur les autres bases de données pendant que j'exécutais ces tests).
Je me rends compte qu'un problème avec les machines virtuelles Azure est que les disques durs sont une ressource réseau, ce qui serait la source du ralentissement, mais il est toujours plus lent même lorsqu'il n'y a aucune lecture physique indiquée dans les statistiques d'E / S.
J'ai suivi les conseils de réglage sur cette page sur la machine virtuelle Azure, notamment le fractionnement des disques (deux disques par lecteur) et la mise en place du journal et des fichiers de données sur des lecteurs distincts.
Les seules choses que je n'ai pas faites sont d'activer la compression de page, de limiter la croissance automatique sur la base de données et de déplacer le journal des erreurs du serveur SQL et les répertoires de fichiers de trace vers les disques de données. Je ne l'ai pas fait non plus sur l'ancien serveur.
L'ancien serveur n'a rien de ce réglage effectué et les fichiers journaux et de données sont sur le même lecteur qui n'est pas rayé.
La base de données sur le serveur actuel est de 65 Go (45 données et 20 journaux), ce qui était un peu trop volumineux pour être transféré vers le nouveau serveur, donc je teste sur une base de données plus petite (6 données et 13,5 journaux)
Les résultats sur l'ancien serveur sont CPU time = 1311 ms, elapsed time = 1057 ms.et sur le nouveau serveur sont CPU time = 1281 ms, elapsed time = 2525 ms. C'est juste une course mais les résultats sont représentatifs de ce que je vois normalement.
Le nouveau serveur semble avoir constamment un temps écoulé bien plus long que le temps CPU. Est-ce un problème et y a-t-il quelque chose que je puisse faire pour trouver la cause du problème?
Quelles autres mesures puis-je prendre pour savoir pourquoi ce serveur va si lentement quand il semble qu'il devrait être plus rapide que l'ancien serveur?
la source
Réponses:
Pour ce qui en vaut la peine, j'ai fini de changer la machine virtuelle dans Azure de type A en type D, puis d'attacher un autre disque et de déplacer TEMPDB sur ce disque. Donc, ma dernière machine virtuelle est maintenant une norme D2 avec 7 Go de RAM et trois disques de données, un pour les fichiers MDF, un autre pour les fichiers LDF et le nouveau disque TEMPDB.
J'ai renoncé à essayer de comprendre avec l'A3 certaines choses que vous avez mentionnées et à simplement mettre à niveau la machine virtuelle. Je suis même passé de A2 à A3 et même si j'ai trouvé des améliorations, j'ai fini par passer à une machine virtuelle D2.
Dans le document que vous avez indiqué, Microsoft recommande un D3 pour Enterprise Edition ou D2 pour Web ou Standard Edition, et l'utilisation de Premium Storage, entre autres choses dans la liste de contrôle au début du document.
la source