Problème de lenteur

Philippe Robert · 26/05/2011, 06h46

* Bonjour, *

Je dispose d'un serveur SQL 2005 SP3 sous Windows 2008. La machine dispose de 16 processeurs et de 70 GB de RAM dont 40 GB sont alloués au service SQL.

Pourtant, nous rencontrons des problèmes de lenteur lors d'exécution de page ASP. Pourtant, les requêtes situées dans les pages ASP fonctionnent très bien lorsqu'elles sont exécutées dans Management Studio. Les applications .NET fonctionnent bien aussi.

Après un redémarrage de SQL serveur, tout est redevenu normal.

Les pages ASP concernées ont été écrites en VB6 et utilisent de vieux pilotes ODBC tandis que le serveur SQL a évolué (passage en SQL 2005 SP2, puis SP3 et bientôt SQL 2008 R2) tandis que les pages ASP n'ont jamais été adaptées depuis une dizaine d'année.

J'ai proposé d'adapter ces pages afin d'utiliser SQL Native Client. Qu'en pensez-vous ? Avez-vous des idées ?

* Merci *

elsuket · 26/05/2011, 08h53

Bonjour,

Citation:

Après un redémarrage de SQL serveur, tout est redevenu normal.

C'est cette piste qu'il faudrait exploiter.

Citation:

les requêtes situées dans les pages ASP fonctionnent très bien lorsqu'elles sont exécutées dans Management Studio

Donc les requêtes ne sont en principe pas en cause.

Y'a-t-il d'autres applications que SQL Server qui sont exécutées sur ce serveur ?
(de l'antivirus à une application "maison", en passant par l'hôte du site)

@++

mikedavem · 26/05/2011, 09h00

Citation:

Donc les requêtes ne sont en principe pas en cause.

Tout dépend. En fonction du contexte d'exécution de la requête dans les pages ASP, un mauvais plan d'exécution peut être généré et du coup avoir un impact sur les performances.

Il existe aussi le problème du parameter sniffing dans ce cas mais il faudrait identifier certaines requêtes et voir ce qui est en cause à l'aide du profiler par exemple.

Citation:

Je dispose d'un serveur SQL 2005 SP3 sous Windows 2008. La machine dispose de 16 processeurs et de 70 GB de RAM dont 40 GB sont alloués au service SQL.

Est ce que cela veut dire que vous venez de faire une migration depuis SQL Server 2000 et que depuis tout va mal ? Précisez un peu

Vérifiez également les éléments externes comme le suggère Elsuket

++

Philippe Robert · 26/05/2011, 09h16

Citation:

Envoyé par elsuket

Y'a-t-il d'autres applications que SQL Server qui sont exécutées sur ce serveur ?
(de l'antivirus à une application "maison", en passant par l'hôte du site)

@++

C'est un serveur dédicacé. Je vais voir au sujet de l'antivirus.

Philippe Robert · 26/05/2011, 09h21

Citation:

Envoyé par mikedavem

Est ce que cela veut dire que vous venez de faire une migration depuis SQL Server 2000 et que depuis tout va mal ? Précisez un peu

Vérifiez également les éléments externes comme le suggère Elsuket

++

Non, nous étions déjà en SQL 2005 SP2 (sur Windows 2003) depuis 2007. Vers la fin de l'année dernière, nous avons migrer sur une autre machine, sous Windows 2008 R2 Enterprise, ainsi que l'installation du SP3 de SQL 2005.

C'est depuis ce moment là que nous avons des problèmes qui semble aller graduellement.

elsuket · 26/05/2011, 09h37

Citation:

Envoyé par Mikedavem

En fonction du contexte d'exécution de la requête dans les pages ASP, un mauvais plan d'exécution peut être généré et du coup avoir un impact sur les performances.

Il existe aussi le problème du parameter sniffing dans ce cas mais il faudrait identifier certaines requêtes et voir ce qui est en cause à l'aide du profiler par exemple.

OK pour la seconde partie. Peux-tu préciser pour la première ?

Citation:

Envoyé par Philippe Robert

C'est un serveur dédicacé.

Par qui ? Steve Ballmer ?

@++

Philippe Robert · 26/05/2011, 09h51

Je rectifie. C'est un serveur dédié

Pour ce qui est des pages ASP, elles sont mal concues car elle fonct trop d'aller-retour entre IIS et SQL server. Cependant, elle ont toujours bien fonctionnés jusqu'a présent.

mikedavem · 26/05/2011, 10h11

Citation:

OK pour la seconde partie. Peux-tu préciser pour la première ?

Les paramètres de connexion peuvent influencer la création des plans d'exécutions. (SET ANSI NULLS, QUOTED IDENTIFIER ...)

J'ai déjà vu ça pour ma part. Une requête SQL qui s'exécute rapidement depuis SSMS alors que depuis une application ASP.net cette même requête prenait énormément de temps.

En regardant les plans d'exécutions générés depuis les 2 environnements on a pu observer que le plan d'éxécution n'était pas du tout le même

++

elsuket · 26/05/2011, 10h18

Intéressant

Les options de session par défaut d'exécution des requêtes sous SSMS sont :

- SET CONCAT_NULL_YIELDS_NULL ON
- SET ARITHABORT ON

Tous les autres à OFF. Et :

- SET TRANSACTION ISOLATION LEVEL READ COMMITTED
- SET DEADLOCK_PRIORITY NORMAL

@++

sacha79 · 26/05/2011, 21h52

Où sont situés tes serveurs WEB ?
As-tu enregistré une trace de blocage et/ou interroge les vues système pour identifier les requêtes incriminées ?

Détail important : Est-ce que les connexions vers le serveur SQL sont systématiquement fermées au niveau applicatif après l'exécution d'une requête ?

26/05/2011, 06h46	#1
Philippe Robert Membre habitué Inscription : janvier 2008 Messages : 212 Détails du profil Informations forums : Inscription : janvier 2008 Messages : 212 Points : 135 Points : 135	Problème de lenteur * Bonjour, * Je dispose d'un serveur SQL 2005 SP3 sous Windows 2008. La machine dispose de 16 processeurs et de 70 GB de RAM dont 40 GB sont alloués au service SQL. Pourtant, nous rencontrons des problèmes de lenteur lors d'exécution de page ASP. Pourtant, les requêtes situées dans les pages ASP fonctionnent très bien lorsqu'elles sont exécutées dans Management Studio. Les applications .NET fonctionnent bien aussi. Après un redémarrage de SQL serveur, tout est redevenu normal. Les pages ASP concernées ont été écrites en VB6 et utilisent de vieux pilotes ODBC tandis que le serveur SQL a évolué (passage en SQL 2005 SP2, puis SP3 et bientôt SQL 2008 R2) tandis que les pages ASP n'ont jamais été adaptées depuis une dizaine d'année. J'ai proposé d'adapter ces pages afin d'utiliser SQL Native Client. Qu'en pensez-vous ? Avez-vous des idées ? * Merci *
	00

26/05/2011, 10h18	#9
elsuket Modérateur Nicolas Souquet Administrateur de base de données Inscription : janvier 2005 Messages : 4 669 Détails du profil Informations personnelles : Nom : Nicolas Souquet Âge : 30 Localisation : Thaïlande Informations professionnelles : Activité : Administrateur de base de données Secteur : High Tech - Éditeur de logiciels Informations forums : Inscription : janvier 2005 Messages : 4 669 Points : 8 729 Points : 8 729	Intéressant Les options de session par défaut d'exécution des requêtes sous SSMS sont : - SET CONCAT_NULL_YIELDS_NULL ON - SET ARITHABORT ON Tous les autres à OFF. Et : - SET TRANSACTION ISOLATION LEVEL READ COMMITTED - SET DEADLOCK_PRIORITY NORMAL @++ __________________ En bases de données relationnelles SQL, il n'y a ni tableaux, ni enregistrements, ni champs: il y a des tables, des lignes et des colonnes. Blog \| Profil\| Consulter ou télécharger les fichiers d'aide de SQL Server, des versions 2000 à 2012
	00

26/05/2011, 09h51	#7
Philippe Robert Membre habitué Inscription : janvier 2008 Messages : 212 Détails du profil Informations forums : Inscription : janvier 2008 Messages : 212 Points : 135 Points : 135	Je rectifie. C'est un serveur dédié Pour ce qui est des pages ASP, elles sont mal concues car elle fonct trop d'aller-retour entre IIS et SQL server. Cependant, elle ont toujours bien fonctionnés jusqu'a présent.
	00

26/05/2011, 21h52	#10
sacha79 Membre à l'essai Inscription : octobre 2006 Messages : 23 Détails du profil Informations forums : Inscription : octobre 2006 Messages : 23 Points : 23 Points : 23	Où sont situés tes serveurs WEB ? As-tu enregistré une trace de blocage et/ou interroge les vues système pour identifier les requêtes incriminées ? Détail important : Est-ce que les connexions vers le serveur SQL sont systématiquement fermées au niveau applicatif après l'exécution d'une requête ?
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email