je constate sur un serveur de production des performances "aléatoires" lors
de l'exécution des procédures stockées.
A titre d'exemple, une procédure s'exécute suivant les cas (mêmes
paramètres, utilisateur unique, pas d'activité autre que mon test) en 14, 7
ou 2 secondes. Le plan d'exécution est strictement le même à chaque exécution.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
bruno reiter [MVP]
Il est possible que ce soit lié à la fragmentation des index, et surtout la première exécution est toujours plus longue car il faut parser la requete, créer le plan d'exec, le compiler et le mettre en cache, alors qu'il est déjà en cache pour les suivantes.
br
"Bertrand RICHARD" <Bertrand wrote in message news:
Bonjour,
je constate sur un serveur de production des performances "aléatoires"
lors
de l'exécution des procédures stockées. A titre d'exemple, une procédure s'exécute suivant les cas (mêmes paramètres, utilisateur unique, pas d'activité autre que mon test) en 14,
7
ou 2 secondes. Le plan d'exécution est strictement le même à chaque
exécution.
Une explication ?
Merci.
Bertrand RICHARD
Il est possible que ce soit lié à la fragmentation des index, et surtout la
première exécution est toujours plus longue car il faut parser la requete,
créer le plan d'exec, le compiler et le mettre en cache, alors qu'il est
déjà en cache pour les suivantes.
br
"Bertrand RICHARD" <Bertrand RICHARD@discussions.microsoft.com> wrote in
message news:AA2251E8-8AF3-466E-9878-9ABCE51C1E71@microsoft.com...
Bonjour,
je constate sur un serveur de production des performances "aléatoires"
lors
de l'exécution des procédures stockées.
A titre d'exemple, une procédure s'exécute suivant les cas (mêmes
paramètres, utilisateur unique, pas d'activité autre que mon test) en 14,
7
ou 2 secondes. Le plan d'exécution est strictement le même à chaque
Il est possible que ce soit lié à la fragmentation des index, et surtout la première exécution est toujours plus longue car il faut parser la requete, créer le plan d'exec, le compiler et le mettre en cache, alors qu'il est déjà en cache pour les suivantes.
br
"Bertrand RICHARD" <Bertrand wrote in message news:
Bonjour,
je constate sur un serveur de production des performances "aléatoires"
lors
de l'exécution des procédures stockées. A titre d'exemple, une procédure s'exécute suivant les cas (mêmes paramètres, utilisateur unique, pas d'activité autre que mon test) en 14,
7
ou 2 secondes. Le plan d'exécution est strictement le même à chaque
exécution.
Une explication ?
Merci.
Bertrand RICHARD
Bertrand RICHARD
Merci pour votre réponse rapide, je vais regarder ce que disent les index. Par contre, pour la première exécution, j'ai effectivement oublié de préciser que je l'ai écartée de mes mesures, sachant qu'elle était faussée par la mise en cache.
Ce qui d'ailleurs m'amène à une "pas tout à fait autre" question : une fois une requête (ou plutôt son plan d'exécution) mis en cache, combien de "temps" y reste-t-il ? ie dans quelles conditions la compilation et remise en cache aura-t-elle de nouveau lieu ?
Merci.
Bertrand RICHARD
"bruno reiter [MVP]" a écrit :
Il est possible que ce soit lié à la fragmentation des index, et surtout la première exécution est toujours plus longue car il faut parser la requete, créer le plan d'exec, le compiler et le mettre en cache, alors qu'il est déjà en cache pour les suivantes.
br
"Bertrand RICHARD" <Bertrand wrote in message news: > Bonjour, > > je constate sur un serveur de production des performances "aléatoires" lors > de l'exécution des procédures stockées. > A titre d'exemple, une procédure s'exécute suivant les cas (mêmes > paramètres, utilisateur unique, pas d'activité autre que mon test) en 14, 7 > ou 2 secondes. Le plan d'exécution est strictement le même à chaque exécution. > > Une explication ? > > Merci. > > Bertrand RICHARD
Merci pour votre réponse rapide, je vais regarder ce que disent les index.
Par contre, pour la première exécution, j'ai effectivement oublié de
préciser que je l'ai écartée de mes mesures, sachant qu'elle était faussée
par la mise en cache.
Ce qui d'ailleurs m'amène à une "pas tout à fait autre" question : une fois
une requête (ou plutôt son plan d'exécution) mis en cache, combien de "temps"
y reste-t-il ? ie dans quelles conditions la compilation et remise en cache
aura-t-elle de nouveau lieu ?
Merci.
Bertrand RICHARD
"bruno reiter [MVP]" a écrit :
Il est possible que ce soit lié à la fragmentation des index, et surtout la
première exécution est toujours plus longue car il faut parser la requete,
créer le plan d'exec, le compiler et le mettre en cache, alors qu'il est
déjà en cache pour les suivantes.
br
"Bertrand RICHARD" <Bertrand RICHARD@discussions.microsoft.com> wrote in
message news:AA2251E8-8AF3-466E-9878-9ABCE51C1E71@microsoft.com...
> Bonjour,
>
> je constate sur un serveur de production des performances "aléatoires"
lors
> de l'exécution des procédures stockées.
> A titre d'exemple, une procédure s'exécute suivant les cas (mêmes
> paramètres, utilisateur unique, pas d'activité autre que mon test) en 14,
7
> ou 2 secondes. Le plan d'exécution est strictement le même à chaque
exécution.
>
> Une explication ?
>
> Merci.
>
> Bertrand RICHARD
Merci pour votre réponse rapide, je vais regarder ce que disent les index. Par contre, pour la première exécution, j'ai effectivement oublié de préciser que je l'ai écartée de mes mesures, sachant qu'elle était faussée par la mise en cache.
Ce qui d'ailleurs m'amène à une "pas tout à fait autre" question : une fois une requête (ou plutôt son plan d'exécution) mis en cache, combien de "temps" y reste-t-il ? ie dans quelles conditions la compilation et remise en cache aura-t-elle de nouveau lieu ?
Merci.
Bertrand RICHARD
"bruno reiter [MVP]" a écrit :
Il est possible que ce soit lié à la fragmentation des index, et surtout la première exécution est toujours plus longue car il faut parser la requete, créer le plan d'exec, le compiler et le mettre en cache, alors qu'il est déjà en cache pour les suivantes.
br
"Bertrand RICHARD" <Bertrand wrote in message news: > Bonjour, > > je constate sur un serveur de production des performances "aléatoires" lors > de l'exécution des procédures stockées. > A titre d'exemple, une procédure s'exécute suivant les cas (mêmes > paramètres, utilisateur unique, pas d'activité autre que mon test) en 14, 7 > ou 2 secondes. Le plan d'exécution est strictement le même à chaque exécution. > > Une explication ? > > Merci. > > Bertrand RICHARD
Bouarroudj Mohamed
> Merci pour votre réponse rapide, je vais regarder ce que disent les index. Par contre, pour la première exécution, j'ai effectivement oublié de préciser que je l'ai écartée de mes mesures, sachant qu'elle était faussée par la mise en cache.
Pour comparer le temps d'excution, vous pouvez vider le cache avant chaque execution (mais pas en Production ;))
DBCC DROPCLEANBUFFERS --La première vide le cache des données DBCC FREEPROCCACHE --La seconde vide le cache contenant les plans de requêtes
Ce qui d'ailleurs m'amène à une "pas tout à fait autre" question : une fois une requête (ou plutôt son plan d'exécution) mis en cache, combien de "temps" y reste-t-il ? ie dans quelles conditions la compilation et remise en cache aura-t-elle de nouveau lieu ?
Vous trouverez la reponse dans le BOL on cherchant par "Aging Execution Plans" ou "Execution Plan Caching and Reuse"
En plus de verifier les indexes, vous pouvez "Recompiler" la SP que vous pensez que les performances sont mauvaises (sp_recompile ...) et voir s'il y'a des ameliorations. Vous pouvez lancer le profiler sur cette procedure (PropertiesFiltersText Data like '%votre sproc%') et verifier le CPU, le Reads et le Writes
Vous pouvez aussi ajouter dans Profiler l'evenement SP:Recompile et si vous trouvez que votre SP est recompilée a chaque execution, la lecture de l'article "Troubleshooting stored procedure recompilation" peut aider (URL : http://support.microsoft.com/kb/q243586/ )
Vous pouvez aussi ajouter l'even SP:StmtCompleted et voir le bout de code qui consomme le plus de temps et essayer de l'optimiser
j'espere que ses petites idées peuvent vous aider et bonne chance dans vos investigations.
> Merci pour votre réponse rapide, je vais regarder ce que disent les index.
Par contre, pour la première exécution, j'ai effectivement oublié de
préciser que je l'ai écartée de mes mesures, sachant qu'elle était faussée
par la mise en cache.
Pour comparer le temps d'excution, vous pouvez vider le cache avant chaque
execution (mais pas en Production ;))
DBCC DROPCLEANBUFFERS --La première vide le cache des données
DBCC FREEPROCCACHE --La seconde vide le cache contenant les plans de
requêtes
Ce qui d'ailleurs m'amène à une "pas tout à fait autre" question : une
fois
une requête (ou plutôt son plan d'exécution) mis en cache, combien de
"temps"
y reste-t-il ? ie dans quelles conditions la compilation et remise en
cache
aura-t-elle de nouveau lieu ?
Vous trouverez la reponse dans le BOL on cherchant par "Aging Execution
Plans" ou "Execution Plan Caching and Reuse"
En plus de verifier les indexes, vous pouvez "Recompiler" la SP que vous
pensez que les performances sont mauvaises (sp_recompile ...) et voir s'il
y'a des ameliorations. Vous pouvez lancer le profiler sur cette procedure
(PropertiesFiltersText Data like '%votre sproc%') et verifier le CPU, le
Reads et le Writes
Vous pouvez aussi ajouter dans Profiler l'evenement SP:Recompile et si vous
trouvez que votre SP est recompilée a chaque execution, la lecture de
l'article "Troubleshooting stored procedure recompilation" peut aider (URL
: http://support.microsoft.com/kb/q243586/ )
Vous pouvez aussi ajouter l'even SP:StmtCompleted et voir le bout de code
qui consomme le plus de temps et essayer de l'optimiser
j'espere que ses petites idées peuvent vous aider et bonne chance dans vos
investigations.
> Merci pour votre réponse rapide, je vais regarder ce que disent les index. Par contre, pour la première exécution, j'ai effectivement oublié de préciser que je l'ai écartée de mes mesures, sachant qu'elle était faussée par la mise en cache.
Pour comparer le temps d'excution, vous pouvez vider le cache avant chaque execution (mais pas en Production ;))
DBCC DROPCLEANBUFFERS --La première vide le cache des données DBCC FREEPROCCACHE --La seconde vide le cache contenant les plans de requêtes
Ce qui d'ailleurs m'amène à une "pas tout à fait autre" question : une fois une requête (ou plutôt son plan d'exécution) mis en cache, combien de "temps" y reste-t-il ? ie dans quelles conditions la compilation et remise en cache aura-t-elle de nouveau lieu ?
Vous trouverez la reponse dans le BOL on cherchant par "Aging Execution Plans" ou "Execution Plan Caching and Reuse"
En plus de verifier les indexes, vous pouvez "Recompiler" la SP que vous pensez que les performances sont mauvaises (sp_recompile ...) et voir s'il y'a des ameliorations. Vous pouvez lancer le profiler sur cette procedure (PropertiesFiltersText Data like '%votre sproc%') et verifier le CPU, le Reads et le Writes
Vous pouvez aussi ajouter dans Profiler l'evenement SP:Recompile et si vous trouvez que votre SP est recompilée a chaque execution, la lecture de l'article "Troubleshooting stored procedure recompilation" peut aider (URL : http://support.microsoft.com/kb/q243586/ )
Vous pouvez aussi ajouter l'even SP:StmtCompleted et voir le bout de code qui consomme le plus de temps et essayer de l'optimiser
j'espere que ses petites idées peuvent vous aider et bonne chance dans vos investigations.
