Étrange problème de performances avec SQL Server 2016

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.

Si votre attente principale est ASYNC_NETWORK_IO, le problème ne vient pas de SQL Server. Cela est presque toujours dû à un goulot d'étranglement de l'application. Je ne parle pas d'un goulot d'étranglement sur le serveur d'applications, mais plutôt d'un goulot d'étranglement dans l'application.

Le goulot d'étranglement de l'application est généralement dû au traitement ligne par ligne pendant que SQL Server envoie les données:

• L'application demande des données à SQL Server
• SQL Server envoie les données rapidement
• L'application indique à SQL Server d'attendre pendant le traitement de chaque ligne
• SQL Server enregistre le temps d'attente pendant ASYNC_NETWORK_IOque l'application lui demande d'attendre

Au lieu de cela, l'application doit consommer toutes les données de SQL Server et ALORS faire son traitement ligne par ligne. SQL Server est hors de vue à ce stade.

sp_BlitzFirst production

L' LCK_M_Sattente n'est pas longue. Il ne contient que 2 secondes de l'échantillon de 30 secondes et sa moyenne n'est que de 400 ms. C'est très, très peu probable que ce soit le problème. ASYNC_NETWORK_IOest votre première attente dans cet exemple. Encore un problème d'application. Si vous voulez de l'aide avec les LCKchoses, nous aurions besoin de voir les requêtes impliquées.

Même ASYNC_NETWORK_IOn'est pas si mal dans cet échantillon. Mes yeux deviennent grands lorsque le temps d'attente est égal ou supérieur à la taille de l'échantillon. C'est là que je creuse.

Tout votre problème est ASYNC_NETWORK_IO. Ce n'est pas un problème SQL Server. C'est un problème avec l'application (faisant le traitement ligne par ligne pendant que SQL Server envoie les données), le serveur d'application (vous avez déjà dit que ça allait) ou le réseau (vous avez dit que le réseau allait bien). Le problème est donc lié à l'application. L'application C ++ doit être corrigée.

Pour répondre à ma propre question: La principale raison pour laquelle ASYNC_NETWORK_IO apparaît sur notre serveur SQL comme type d'attente supérieur, est que le energy savingparamètre du serveur Windows a été défini sur au 'balanced'lieu de 'high performance'. Nous avons ensuite parlé à certains administrateurs de vm ware, et ils ont tous dit que ce paramètre tue les performances .

Les solutions pour cela sont soit:

• N'installez pas le contrôle d'énergie lors de l'installation du serveur Windows
• Définissez le mode d'économie d'énergie sur hautes performances pour tous les serveurs via une stratégie de groupe

Tous les autres problèmes / statistiques concernant ASYNC_NETWORK_IO sont liés au fait que notre application ERP est mal écrite. Merci à tous ceux qui m'ont aidé à résoudre ce problème, vos commentaires, suggestions et conseils ont été les bienvenus et utiles!