Nous avons une seule instance de SQL Server 2016 SP1 exécutée sur une machine virtuelle VMware. Il contient 4 bases de données, chacune pour une application différente. Ces applications sont toutes sur des serveurs virtuels séparés. Aucun d'entre eux n'est encore utilisé en production. Les personnes qui testent les applications signalent cependant des problèmes de performances.
Ce sont les statistiques du serveur:
- 128 Go de RAM (110 Go de mémoire max pour SQL Server)
- 4 cœurs à 4,6 GHz
- Connexion réseau de 10 Go
- Tout le stockage est basé sur SSD
- Les fichiers programme, les fichiers journaux, les fichiers de base de données et tempdb se trouvent sur des partitions distinctes du serveur
- asd
Les utilisateurs effectuent un accès à un seul écran via une application ERP basée sur C ++.
Lorsque je teste le SQL Server avec Microsoft en ostressutilisant de nombreuses petites requêtes ou une grande requête, j'obtiens des performances maximales. La seule chose qui limite est le client, car il ne peut pas répondre assez rapidement.
Mais quand il n'y a pratiquement pas d'utilisateurs, SQL Server ne fait pratiquement rien. Pourtant, les gens doivent attendre indéfiniment juste pour enregistrer quoi que ce soit dans l'application.
Selon la requête " Dites-moi où ça fait mal " de Paul Randal , 50% de tous les événements d'attente le sont ASYNC_NETWORK_IO.
Cela peut signifier soit un problème de réseau, soit un problème de performances avec le serveur d'applications ou le client. Aucun d'entre eux n'utilise même ses ressources à distance à pleine capacité. La plupart du temps, le CPU est d'environ 26% sur toutes les machines (client, serveur d'applications, serveur db).
La latence de la connexion réseau est d'environ 1 à 3 ms. L'E / S du serveur db est à une vitesse d'écriture maximale de 20 Mo / s lors d'une utilisation normale avec l'application (la moyenne est de 7 à 9 Mo / s). Lorsque je fais un test de stress, je me déplace autour de 5 Go / s maximum.
La taille du cache tampon est de 60 Go pour la base de données de notre système ERP, 20 Go pour notre logiciel de financement, 1 Go pour le logiciel d'assurance qualité, 3 Go pour le système d'archivage de documents.
J'ai donné au compte SQL Server le droit d'utiliser l' initialisation instantanée des fichiers . Cela n'a pas du tout augmenté les performances.
L'espérance de vie des pages est d'environ 15 000+ pendant une utilisation normale. Chute à environ .05k à la fin des tests de résistance, ce qui est à prévoir. Les lots / s se situent autour de 2 à 8 000, selon la charge de travail.
Je dirais que l'application ERP est mal écrite, mais je ne peux pas car toutes les applications sont affectées. Même avec une charge de travail minimale.
Pourtant, je ne peux pas déterminer exactement ce qui cause cela. Y a-t-il des conseils, des astuces, des didacticiels, des applications, des documents sur les meilleures / pires pratiques ou toute autre chose que vous avez en tête concernant ce problème?
Ce sont les résultats de sp_BlitzFirst:
Je l'ai couru 600 secondes. Je l'ai démarré pendant une charge de travail élevée de l'application. 1/3 du temps c'est ASYNC_NETWORK_IO. J'ai aussi testé la connexion réseau avec NTttcp, PsPing, ipferf3et pathping. Rien d'inhabituel. Les temps de réponse sont au maximum de 3 ms, en moyenne 0,3 ms. Le débit est d'environ 1000 Mo / s.
Mon enquête aboutit toujours à ASYNC_NETWORK_IOêtre le numéro un des serveurs.
Nous avons étudié le résultat de la désactivation de la Large-Receive-Offloadfonctionnalité dans VMware. Nous testons toujours, mais les résultats semblent contradictoires. Notre premier `` benchmark '' a entraîné une durée de 19 minutes (le meilleur résultat est 13 minutes, ce qui n'est atteint que lorsque l'application s'exécute sur la machine virtuelle avec SQL Server lui-même). Le deuxième résultat est 28 minutes, ce qui est vraiment mauvais.
Le premier résultat de notre «benchmark» était de 19 minutes. Ce qui est bon. Parce que le meilleur résultat était de 13 minutes (ce qui n'est possible que lorsque les tests de performances de l'application sur la machine virtuelle avec SQL Server lui-même). Cela suggère fortement un problème lié au réseau. Ou un problème avec la configuration VMware.
Je suis actuellement perdu sur les méthodes à utiliser, pour le clouer au goulot d'étranglement.
Les performances maximales avec l'application ne sont réalisables que lorsque l'application s'exécute sur la machine virtuelle avec SQL Server lui-même. Si l'application est exécutée sur une autre machine virtuelle ou un bureau virtuel, la durée de notre benchmark est triplée (de 13 minutes à 40 minutes ou plus). Tous les points de terminaison (VM de SQL Server, VM du serveur d'applications et Virtual Desktop) utilisent le même matériel physique. Nous avons déplacé tous les autres points de terminaison vers un autre matériel.
EDIT: On dirait que le problème est de retour. Après avoir réglé le mode d'économie d'énergie de équilibré à haute performance, nous avons amélioré considérablement les temps de réponse. Mais aujourd'hui, j'ai de nouveau exécuté sp_BlitzFirst, avec un échantillon de 300 secondes. Voici le résultat:
Il affiche plus de secondes d'attente pour ASYNC_NETWORK_IO que les secondes que sp_blitzfirst a exécutées.
la source