performances de simultanéité du serveur SQL

Nous avons rencontré des problèmes de performances sur notre environnement de production.

nous avons constaté que lorsque les sessions actives dépassent 25, l'utilisation du processeur atteint 100% et il faut beaucoup de temps pour descendre.

L'environnement que nous avons:

Produit Microsoft SQL Server Enterprise Edition 9.3 (sp2)

CPU 2 (Xeon 2.13)

Mémoire 7G

instantané du détail de la session1

Sessions actives 25

Transactions actives 496

Séances inactives 289

Transactions bloquées 29

instantané du détail de la session2

Sessions actives 59

Transactions actives 885

Séances inactives 267

Transactions bloquées 49

J'aimerais savoir:

1. si les 2CPU peuvent bien gérer 25 sessions actives (500 transactions actives) .PS: nous avons testé que sans demande de concurrence, une transaction, qui lit / écrit 5 tables, prend environ 1 seconde au niveau de l'application.

2. si les transactions bloquées prennent plus d'utilisation du processeur.PS: les transactions bloquées sont principalement dues aux verrous sur 2 tables.

quelle est la solution: ajouter des CPUs ou une application de tuning (java / hibernate) pour raccourcir cette transaction et diminuer les blocs sur la table?

Vos options pour avoir une bonne image de la situation lorsque tout se déroule:

• utiliser les traces côté serveur pour voir les sessions les plus longues et les plus lourdes
• utilisez la procédure stockée Who is Active d'Adam Machanic - pour enregistrer les informations sur les moments où le serveur est chargé - fantastique script gratuit
• utiliser le moniteur d'activité de Management Studio juste pour avoir un aperçu visuel (Cpu et IO sont ceux que j'ai trouvé les plus utiles) - un très bon outil inclus dans Management Studio
• utilisez un outil gratuit tiers - Confio Ignite Free - qui est très bon pour les moments où tout est lent et doit voir les détails sur les statistiques d'attente, blocking..etc. - fantastique outil gratuit
• vérifier les statistiques pour être à jour
• vérifier si les index sont fragmentés et, le cas échéant, les défragmenter
• suivre les autres conseils de vérification des index manquants, conception
• vérifiez la possibilité d'utiliser le niveau d'isolement de l' instantané dans votre base de données (vous avez un blocage élevé, il est donc bon de voir si vous avez vraiment besoin de votre niveau d'isolement actuel)

Et bonne chance pour enquêter sur les problèmes :-).

Votre problème est probablement une mauvaise performance des requêtes due à

• mauvaise conception
• mauvaise indexation

Les verrous / blocages proviennent d'une mauvaise indexation en raison de tout le temps passé à analyser les tables de bout en bout. Le CPU n'est pas pertinent ici.

À titre de solution rapide, recherchez les index manquants à l'aide des informations de cet article: http://blogs.msdn.com/b/bartd/archive/2007/07/19/are-you-using-sql-s-missing- index-dmvs.aspx

Je suis d'accord avec GBN et Marian.

Pour répondre à votre question concernant les 2 processeurs traitant 25 demandes: J'ai un système à 2 processeurs qui prend en charge environ 750 connexions utilisateur et une moyenne courante de demandes de lots 4K par seconde. Plusieurs éléments sont importants pour moi: la conception, la gestion et le réglage. Si vous commencez avec une mauvaise conception de votre application et de votre base de données, vous échouerez à la charge (pensez à la mise à l'échelle).

Un CPU élevé peut indiquer une pression mémoire. Vous mentionnez que SQL Server ne dispose que de 7 Go de mémoire. Si vous avez des index peu performants (trop d'index, des index incorrects ou pas d'index), cela entraînera le système à paginer davantage de la base de données en mémoire pour diverses requêtes, puis s'il existe des index appropriés. Je vous conseille de ne pas créer d'index comme des porcs, car les mauvais vous blesseront également car chacun a le potentiel de nécessiter une mise à jour au cours d'une opération de mise à jour de ligne (Créer-Mettre à jour-Supprimer).

En outre, l'utilisation des DMV d'index manquant nécessite l'utilisation de ce que vous savez de votre application et de votre base de données et pas seulement la mise en œuvre de chaque index recommandé. Je voudrais vérifier les entrées du blog de Kimberly Tripp concernant les index ici . Après la section Index, regarder les autres catégories pourrait vous être utile.

Si votre mise à jour Java / Hibernate de 5 tables en une seule transaction effectue les mises à jour via plusieurs allers-retours à la base de données, alors vous vous exposez à des conflits (demandes CRUD bloquées). Le problème s'aggrave si l'application n'est pas en mesure de revenir à la base de données en temps opportun. Dans l'application, la transaction active associée peut bloquer le traitement d'autres demandes et entraîner des délais d'attente.

Ajoutez les deux problèmes ci-dessus ensemble et vous commencez à avoir un cas désagréable de maux de tête de performance.

Réduire le nombre d’aller-retours dans la base de données dans le cadre d’une seule transaction serait une très bonne chose à poursuivre. Peut-être qu'une procédure stockée aiderait.

Le reste nécessitera du travail afin de faire évoluer votre application. Vous pouvez également envisager la mémoire, mais cela devrait venir après une révision de la conception et des performances et les modifications nécessaires mises en œuvre car l'ajout immédiat de mémoire masquera vos problèmes.

Suivez absolument les suggestions de Marian.

Je dirais que vous vous êtes trouvé un formidable défi et vous souhaite beaucoup de succès!

1. Dans mon expérience, nous avons MS SQL Server 2000 avec 2 processeurs et plus de 30 sessions actives et plus de 1000 transactions. C'était difficile à gérer, mais cela a fonctionné.
2. Je ne suis pas sûr que les verrous utilisent plus de CPU. Les verrous et l'utilisation du processeur sont, à mon avis, deux problèmes de performances différents.

En ce qui concerne la solution, vous devez d'abord vous assurer que votre problème principal est le CPU. Essayez de lire ce problème pour trouver la source de vos problèmes et obtenir une solution appropriée. Enfin, si vous pouvez rendre votre transaction aussi petite que possible, faites-le.

Mes premières pensées sont de réduire le nombre de transactions et de réduire le nombre de blocages. Pouvez-vous séparer certaines des transactions en plusieurs bits? Pouvez-vous extraire certaines des requêtes des transactions? Comme Alex_l l'a mentionné - la plus petite transaction possible est idéale ici.

Je suis d'accord avec gbn, l'ajout d'index pourrait également aider.

Une autre pensée est que je voudrais également jeter un œil à vos serrures. Supprimez-vous des verrous au niveau de la table lorsque vous ne mettez à jour qu'une seule ligne? Vous pourriez envisager de suggérer un verrou de niveau ligne à SQL Server. Cela résoudrait beaucoup de problèmes. (Certes, si vous avez 5 tables, ce n'est probablement pas le cas, mais juste une pensée.)

Enfin, je voudrais jeter un oeil à vos tables que vous utilisez. Si tout le monde bloque sur une table particulière, pouvez-vous déplacer la logique de cette table à la fin de votre transaction? Si vous pouvez réduire le temps que vous maintenez un verrou sur cette table à forte demande, cela pourrait aider.