Le délai d'attente écoulé avant l'obtention d'une connexion à partir du pool

Notre site fonctionne très bien pour 90% de la journée, puis pendant nos heures de pointe, lorsque le trafic est environ deux fois plus lourd que la normale, tout ralentit à un rampement. Temps de chargement des pages qui sont normalement de 1 seconde de prendre 30 secondes. Vérifier les journaux d'erreur, il ressemble, il peut être un pool de connexions question. Nous avons 3 serveurs web lié à 1 db sql server. Le serveur SQL est en train de voler au-dessous de 25% d'utilisation sur tous les cœurs.

Je regarde les Connexions de l'Utilisateur compteur sur notre SQL server et de voir que lors de notre sommet, nous avons plus de 400 Connexions Utilisateur, mais hors des heures de travail, il est autour de 120+.

Je suis assez sûr que nous sommes juste en utilisant tous les paramètres par défaut de MS est livré avec faire avec notre app de la piscine. Que puis-je faire pour tester pour voir si est une application de la piscine problème? Quels sont les points négatifs de l'augmentation de l'application de la taille du pool de 1000 (et comment dois-je faire cela?).

Merci!

source d'informationauteur Hawk | 2009-10-29

15

Dans mon expérience, il existe 3 principaux types de délais d'attente, vous pouvez recevoir à partir de SQL Server:

1) InvalidOperationException - Un échec pour le client d'obtenir un regroupement de connexion à partir de son propre piscine avant le délai spécifié sur la chaîne de commande (par défaut 15 secondes). Le client de la piscine est à sa taille maximale, et tout mis en commun les connexions sont en cours d'utilisation et restent en usage avant le délai est écoulé.

2) SQLException - Délai D'Attente De Connexion. La connexion du client de la piscine est la création d'une nouvelle connexion à la base de données, mais la base de données ne répond pas avant le délai spécifié dans la chaîne de commande (par défaut 15 secondes).

3) SQLException - Commande Timeout. Une connexion a été obtenue, mais le temps pris pour l'instruction SQL à l'exercice de la commande dépassé le délai spécifié sur la commande de la propriété CommandTimeout (par défaut: 30 secondes)

Votre situation d'un serveur performant normalement jusqu'à ce que la charge est ajoutée sonne comme le cas n ° 1. J'ai trouvé les délais d'attente sont très rapide - généralement de 2 secondes.

J'ai trouvé la solution à ce problème est d'augmenter le montant maximum de threads dans SQL Server. La valeur par défaut est zéro - laissez SQL Server décider. J'ai vu des cas où un gros serveur se trouve à peu de l'utilisation des ressources tandis qu'il a limité par l'allocation d'un trop petit nombre de threads.

Vous pouvez augmenter le max de threads avec cet transact-sql:
```
sp_configure 'max worker threads', 8192
go
Reconfigure 
```
Ensuite, redémarrez le Service SQL.

BTW, vous pouvez voir combien de fils sont actuellement alloués par SQL Server avec cette commande:
```
select sum(current_workers_count) from sys.dm_os_schedulers
```
Ce filetage réglage fait une énorme différence dans la façon dont SQL Server effectue dans de nombreuses connexions. SQL Server cesse de répondre très fois qu'il exécute des threads.
7

Cela pourrait être lié aux connexions sql ne sont pas correctement éliminés (renvoyé à la piscine). Assurez-vous que vous appelez SqlConnection.Dispose.
5

Ce pourrait être parce que le pool de Connexions SQL est épuisé (ce qui est différent de l'application de la piscine.) Vous pouvez le vérifier en l'augmentation de la taille du pool à travers la chaîne de connexion:
```
Integrated Security=SSPI;Initial Catalog=northwind;Max Pool Size=100;
```
Mais plus probablement, votre base de données ne peut pas maintenir le flux de la réception des requêtes. Cela provoque des connexions en attente de leur requête à la fin. En ajoutant plus de connexions contre l'éclatement des demandes, mais pas contre la hausse soutenue du trafic.

Voici quelques suggestions pour améliorer les performances de votre Serveur SQL server sous soutenue de charge:
- Jeter le matériel sur le problème (surtout de la RAM sur le Serveur SQL server)
- Joindre générateur de profils SQL Server pour le serveur, obtenir une trace de l'un de haut de la charge de la période, et de suivre son index
- De le journal de suivi, d'examiner des requêtes de longue durée, et d'améliorer ceux avec un T-SQL developer
Bonne chance, ces choses peuvent être assez complexes!

Quand j'ai reçu ce message d'erreur:

Le délai écoulé avant l'obtention d'une connexion à partir de la
piscine. Cela peut avoir lieu, car toutes les connexions ont été mis en commun dans
l'utilisation et max de la taille du pool a été atteint

C'était dû au fait que j'ai été en utilisant le SqlCommand.ExecuteQuery() méthode au lieu de SqlCommand.ExecuteNonQuery().

Par exemple: Mon enregistré d'origine procdure appel ressembler à quelque chose comme ceci:

using (SqlCommand cmd = new SqlCommand())
{
    cmd.CommandType = System.Data.CommandType.StoredProcedure;
    cmd.CommandText = "InsertSproc";
    cmd.Parameters.AddWithValue("@Value", myValue);
    cmd.Parameters.AddWithValue("@LoggedDate", myDate);
    DatabaseManager.instance.ExecuteQuery(cmd);
}

Le code ci-dessus est ce qui a déclenché l'exception. Toutefois, la modification de l'appel pour utiliser la méthode ExecuteNonQuery() fixe le problème:

using (SqlCommand cmd = new SqlCommand())
{
    cmd.CommandType = System.Data.CommandType.StoredProcedure;
    cmd.CommandText = "InsertSproc";
    cmd.Parameters.AddWithValue("@Value", myValue);
    cmd.Parameters.AddWithValue("@LoggedDate", myDate);
    DatabaseManager.instance.ExecuteNonQuery(cmd);
}

1

J'ai eu ce problème avec Powershell et dos à dos les requêtes (invoke-sqlcmd suivi par un autre invoke-sqlcmd). Les deux requêtes concernées, les modifications de données. Résolu en ajoutant -connectiontimeout 1 pour le paramètre d'appel.

Exemple:
```
invoke-sqlcmd "insert into testdb..tab1 (cname) select 'x'" -connectiontimeout 1
invoke-sqlcmd "update testdb..tab1 set ctr=ctr+1 where cname='aaa'"
```
Durée du délai d'attente peut varier selon le nombre de lignes affectées.

Vous devez vous connecter pour publier un commentaire.