Bonjour,
Dans le cadre de mon boulot j'ai un gros problème de performances sur un
serveur SQL (SQL 2000 Entreprise SP4) où les 4 CPU (8 en hyper threading)
sont bloqués à 100% pendant des heures !
Quels outils me conseillez vous pour mener à bien mes investigations et
tester ce qui peut poser problème ?
Merci d'avance pour vos réponses :)
--
Christophe - MVP Windows Mobile
http://www.windows-mobile.info/
Bonjour,
Dans le cadre de mon boulot j'ai un gros problème de performances sur un
serveur SQL (SQL 2000 Entreprise SP4) où les 4 CPU (8 en hyper threading)
sont bloqués à 100% pendant des heures !
Quels outils me conseillez vous pour mener à bien mes investigations et
tester ce qui peut poser problème ?
Merci d'avance pour vos réponses :)
--
Christophe - MVP Windows Mobile
http://www.windows-mobile.info/
Bonjour,
Dans le cadre de mon boulot j'ai un gros problème de performances sur un
serveur SQL (SQL 2000 Entreprise SP4) où les 4 CPU (8 en hyper threading)
sont bloqués à 100% pendant des heures !
Quels outils me conseillez vous pour mener à bien mes investigations et
tester ce qui peut poser problème ?
Merci d'avance pour vos réponses :)
--
Christophe - MVP Windows Mobile
http://www.windows-mobile.info/
Bonjour,
Dans le cadre de mon boulot j'ai un gros problème de performances sur un
serveur SQL (SQL 2000 Entreprise SP4) où les 4 CPU (8 en hyper threading)
sont bloqués à 100% pendant des heures !
Quels outils me conseillez vous pour mener à bien mes investigations et
tester ce qui peut poser problème ?
Merci d'avance pour vos réponses :)
Bonjour,
Dans le cadre de mon boulot j'ai un gros problème de performances sur un
serveur SQL (SQL 2000 Entreprise SP4) où les 4 CPU (8 en hyper threading)
sont bloqués à 100% pendant des heures !
Quels outils me conseillez vous pour mener à bien mes investigations et
tester ce qui peut poser problème ?
Merci d'avance pour vos réponses :)
Bonjour,
Dans le cadre de mon boulot j'ai un gros problème de performances sur un
serveur SQL (SQL 2000 Entreprise SP4) où les 4 CPU (8 en hyper threading)
sont bloqués à 100% pendant des heures !
Quels outils me conseillez vous pour mener à bien mes investigations et
tester ce qui peut poser problème ?
Merci d'avance pour vos réponses :)
salut,
Christophe Cordonnier a écrit :
> Bonjour,
>
> Dans le cadre de mon boulot j'ai un gros problème de performances sur un
> serveur SQL (SQL 2000 Entreprise SP4) où les 4 CPU (8 en hyper
> sont bloqués à 100% pendant des heures !
>
> Quels outils me conseillez vous pour mener à bien mes investigations et
> tester ce qui peut poser problème ?
utilitaire perfmon.exe
table master..sysperfinfo
profiler SQL
...
Mais pour ce qui est de l'yperthreading, peut être êtes vous victime du
problème mis en lumière par Slava oks :
http://blogs.msdn.com/slavao/archive/2005/11/12/492119.aspx
A +
>
> Merci d'avance pour vos réponses :)
>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
salut,
Christophe Cordonnier a écrit :
> Bonjour,
>
> Dans le cadre de mon boulot j'ai un gros problème de performances sur un
> serveur SQL (SQL 2000 Entreprise SP4) où les 4 CPU (8 en hyper
> sont bloqués à 100% pendant des heures !
>
> Quels outils me conseillez vous pour mener à bien mes investigations et
> tester ce qui peut poser problème ?
utilitaire perfmon.exe
table master..sysperfinfo
profiler SQL
...
Mais pour ce qui est de l'yperthreading, peut être êtes vous victime du
problème mis en lumière par Slava oks :
http://blogs.msdn.com/slavao/archive/2005/11/12/492119.aspx
A +
>
> Merci d'avance pour vos réponses :)
>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
salut,
Christophe Cordonnier a écrit :
> Bonjour,
>
> Dans le cadre de mon boulot j'ai un gros problème de performances sur un
> serveur SQL (SQL 2000 Entreprise SP4) où les 4 CPU (8 en hyper
> sont bloqués à 100% pendant des heures !
>
> Quels outils me conseillez vous pour mener à bien mes investigations et
> tester ce qui peut poser problème ?
utilitaire perfmon.exe
table master..sysperfinfo
profiler SQL
...
Mais pour ce qui est de l'yperthreading, peut être êtes vous victime du
problème mis en lumière par Slava oks :
http://blogs.msdn.com/slavao/archive/2005/11/12/492119.aspx
A +
>
> Merci d'avance pour vos réponses :)
>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
d'ailleurs comment pouvons nous 鳲e sur que notre hyperthreading nous aide
ou pas ?
y'a t'il des personnes qui qui on ecrit des scripts pour mettre en evidence
le probleme ?
comme le bug des P90 �'epoque ?
d'ailleurs comment pouvons nous 鳲e sur que notre hyperthreading nous aide
ou pas ?
y'a t'il des personnes qui qui on ecrit des scripts pour mettre en evidence
le probleme ?
comme le bug des P90 �'epoque ?
d'ailleurs comment pouvons nous 鳲e sur que notre hyperthreading nous aide
ou pas ?
y'a t'il des personnes qui qui on ecrit des scripts pour mettre en evidence
le probleme ?
comme le bug des P90 �'epoque ?
bonjour,
Un des problèmes de base de l'hyperthreading avec SQL 2000 est sa
difficulté à bien déterminer combien de processeurs physiques sont
disponibles. Je ne peux que vous conseiller (et Microsoft le recommande
également), de limiter le parallélisme à votre nombre de processeurs
physique (cad 2x moins que les processeurs affichés).
Faites un
EXEC sp_configure 'max degree of parallelism', 4
RECONFIGURE WITH OVERRIDE
en tournant perfmon, et regardez l'évolution de vos CPUs. C'est souvent
spectaculaire.
> d'ailleurs comment pouvons nous ?e sur que notre hyperthreading nous
> ou pas ?
> y'a t'il des personnes qui qui on ecrit des scripts pour mettre en
> le probleme ?
>
> comme le bug des P90 ?'epoque ?
bonjour,
Un des problèmes de base de l'hyperthreading avec SQL 2000 est sa
difficulté à bien déterminer combien de processeurs physiques sont
disponibles. Je ne peux que vous conseiller (et Microsoft le recommande
également), de limiter le parallélisme à votre nombre de processeurs
physique (cad 2x moins que les processeurs affichés).
Faites un
EXEC sp_configure 'max degree of parallelism', 4
RECONFIGURE WITH OVERRIDE
en tournant perfmon, et regardez l'évolution de vos CPUs. C'est souvent
spectaculaire.
> d'ailleurs comment pouvons nous ?e sur que notre hyperthreading nous
> ou pas ?
> y'a t'il des personnes qui qui on ecrit des scripts pour mettre en
> le probleme ?
>
> comme le bug des P90 ?'epoque ?
bonjour,
Un des problèmes de base de l'hyperthreading avec SQL 2000 est sa
difficulté à bien déterminer combien de processeurs physiques sont
disponibles. Je ne peux que vous conseiller (et Microsoft le recommande
également), de limiter le parallélisme à votre nombre de processeurs
physique (cad 2x moins que les processeurs affichés).
Faites un
EXEC sp_configure 'max degree of parallelism', 4
RECONFIGURE WITH OVERRIDE
en tournant perfmon, et regardez l'évolution de vos CPUs. C'est souvent
spectaculaire.
> d'ailleurs comment pouvons nous ?e sur que notre hyperthreading nous
> ou pas ?
> y'a t'il des personnes qui qui on ecrit des scripts pour mettre en
> le probleme ?
>
> comme le bug des P90 ?'epoque ?
si je comprends bien nous avons un bi opteron
donc dans le systeme 4 cpu mais en vrai 2
il faudrait mettre ???
EXEC sp_configure 'max degree of parallelism', 2
RECONFIGURE WITH OVERRIDE
Toutefois la valeur actuelle est
'max degree of parallelism' ,0, 32, 0, 0
quand j'applique j'ai !
'max degree of parallelism' ,0, 32, 2, 0
comment ce comporte t'il ?
avec les 2 cpus sans hyperthreading ? ou 1 cpu + hyper ??
Merci par avance !
si je comprends bien nous avons un bi opteron
donc dans le systeme 4 cpu mais en vrai 2
il faudrait mettre ???
EXEC sp_configure 'max degree of parallelism', 2
RECONFIGURE WITH OVERRIDE
Toutefois la valeur actuelle est
'max degree of parallelism' ,0, 32, 0, 0
quand j'applique j'ai !
'max degree of parallelism' ,0, 32, 2, 0
comment ce comporte t'il ?
avec les 2 cpus sans hyperthreading ? ou 1 cpu + hyper ??
Merci par avance !
si je comprends bien nous avons un bi opteron
donc dans le systeme 4 cpu mais en vrai 2
il faudrait mettre ???
EXEC sp_configure 'max degree of parallelism', 2
RECONFIGURE WITH OVERRIDE
Toutefois la valeur actuelle est
'max degree of parallelism' ,0, 32, 0, 0
quand j'applique j'ai !
'max degree of parallelism' ,0, 32, 2, 0
comment ce comporte t'il ?
avec les 2 cpus sans hyperthreading ? ou 1 cpu + hyper ??
Merci par avance !
Christophe a écrit:si je comprends bien nous avons un bi opteron
donc dans le systeme 4 cpu mais en vrai 2
il faudrait mettre ???
EXEC sp_configure 'max degree of parallelism', 2
RECONFIGURE WITH OVERRIDE
Toutefois la valeur actuelle est
'max degree of parallelism' ,0, 32, 0, 0
quand j'applique j'ai !
'max degree of parallelism' ,0, 32, 2, 0
comment ce comporte t'il ?
avec les 2 cpus sans hyperthreading ? ou 1 cpu + hyper ??
Merci par avance !
je vous avais donné quatre selon votre premier post où vous parliez de 4
CPUs. Dans ce cas, c'est bien 2.
en effet, vous êtes passé d'un maxdop à 0 (illimité) à 2. Avez-vous noté
une différence de charge de CPU ? Sur un serveur que j'ai eu l'occasion
d'administrer il y a qq mois, l'effet était presque immédiat.
Pour le comportement, il ne devrait pas y avoir de problème de confusion
avec SQL Server. Les deux CPUs physiques devraient être correctement
utilisés. En cas de problème, vous pouvez essayer de descendre à 1, cad de
désactiver le parallélisme. Si votre serveur est très sollicité, le
parallélisme n'est probablement pas utile.
Qq petits trucs sur le parallélisme: vous pouvez tracer avec le profiler
un
des évènements de parallélisme dans les évènements de performance (tracer
un seul de ces évènement est suffisant dans SQL 2000). Dans la colonne
EventSubClass data vous trouverez le type de requête (select, update,.),
le
nb de CPUs utilisé est dans BinaryData.
Pour faire des essais, l'utilisation du trace flag 8687 désactive le
parallélisme pour une connexion. Ca vous permet de faire des essais avec
des appels de sp par exemple.
Vous pouvez également appeler
DBCC SQLPERF(WAITSTATS)
et regarder le nombre de waits de type CXPACKET, qui indiquent des
attentes
dûes au parallélisme (un processus qui attend la fin d'un de ses threads).
Si vous voyez en grand nombre, cela signifie qu'il y a eu beaucoup de
waits
de ce type depuis le lancement de SQL Server.
Ceci est lisible sur mon blog
http://www.babaluga.org/blog/archives/2005/03/30/max-degree-of-parallelism/
avec des liens sur d'autres ressources.
Si vos CPUs sont toujours à 100%, peut-être s'agit-il d'un autre problème,
par exemple un grand nombre de scans dû à des requêtes mal optimisées ou
un
manque d'index, ou simplement une trop grande charge du serveur.
--
Rudi Bruchez - MCDBA
http://www.babaluga.com/
Christophe a écrit:
si je comprends bien nous avons un bi opteron
donc dans le systeme 4 cpu mais en vrai 2
il faudrait mettre ???
EXEC sp_configure 'max degree of parallelism', 2
RECONFIGURE WITH OVERRIDE
Toutefois la valeur actuelle est
'max degree of parallelism' ,0, 32, 0, 0
quand j'applique j'ai !
'max degree of parallelism' ,0, 32, 2, 0
comment ce comporte t'il ?
avec les 2 cpus sans hyperthreading ? ou 1 cpu + hyper ??
Merci par avance !
je vous avais donné quatre selon votre premier post où vous parliez de 4
CPUs. Dans ce cas, c'est bien 2.
en effet, vous êtes passé d'un maxdop à 0 (illimité) à 2. Avez-vous noté
une différence de charge de CPU ? Sur un serveur que j'ai eu l'occasion
d'administrer il y a qq mois, l'effet était presque immédiat.
Pour le comportement, il ne devrait pas y avoir de problème de confusion
avec SQL Server. Les deux CPUs physiques devraient être correctement
utilisés. En cas de problème, vous pouvez essayer de descendre à 1, cad de
désactiver le parallélisme. Si votre serveur est très sollicité, le
parallélisme n'est probablement pas utile.
Qq petits trucs sur le parallélisme: vous pouvez tracer avec le profiler
un
des évènements de parallélisme dans les évènements de performance (tracer
un seul de ces évènement est suffisant dans SQL 2000). Dans la colonne
EventSubClass data vous trouverez le type de requête (select, update,.),
le
nb de CPUs utilisé est dans BinaryData.
Pour faire des essais, l'utilisation du trace flag 8687 désactive le
parallélisme pour une connexion. Ca vous permet de faire des essais avec
des appels de sp par exemple.
Vous pouvez également appeler
DBCC SQLPERF(WAITSTATS)
et regarder le nombre de waits de type CXPACKET, qui indiquent des
attentes
dûes au parallélisme (un processus qui attend la fin d'un de ses threads).
Si vous voyez en grand nombre, cela signifie qu'il y a eu beaucoup de
waits
de ce type depuis le lancement de SQL Server.
Ceci est lisible sur mon blog
http://www.babaluga.org/blog/archives/2005/03/30/max-degree-of-parallelism/
avec des liens sur d'autres ressources.
Si vos CPUs sont toujours à 100%, peut-être s'agit-il d'un autre problème,
par exemple un grand nombre de scans dû à des requêtes mal optimisées ou
un
manque d'index, ou simplement une trop grande charge du serveur.
--
Rudi Bruchez - MCDBA
http://www.babaluga.com/
Christophe a écrit:si je comprends bien nous avons un bi opteron
donc dans le systeme 4 cpu mais en vrai 2
il faudrait mettre ???
EXEC sp_configure 'max degree of parallelism', 2
RECONFIGURE WITH OVERRIDE
Toutefois la valeur actuelle est
'max degree of parallelism' ,0, 32, 0, 0
quand j'applique j'ai !
'max degree of parallelism' ,0, 32, 2, 0
comment ce comporte t'il ?
avec les 2 cpus sans hyperthreading ? ou 1 cpu + hyper ??
Merci par avance !
je vous avais donné quatre selon votre premier post où vous parliez de 4
CPUs. Dans ce cas, c'est bien 2.
en effet, vous êtes passé d'un maxdop à 0 (illimité) à 2. Avez-vous noté
une différence de charge de CPU ? Sur un serveur que j'ai eu l'occasion
d'administrer il y a qq mois, l'effet était presque immédiat.
Pour le comportement, il ne devrait pas y avoir de problème de confusion
avec SQL Server. Les deux CPUs physiques devraient être correctement
utilisés. En cas de problème, vous pouvez essayer de descendre à 1, cad de
désactiver le parallélisme. Si votre serveur est très sollicité, le
parallélisme n'est probablement pas utile.
Qq petits trucs sur le parallélisme: vous pouvez tracer avec le profiler
un
des évènements de parallélisme dans les évènements de performance (tracer
un seul de ces évènement est suffisant dans SQL 2000). Dans la colonne
EventSubClass data vous trouverez le type de requête (select, update,.),
le
nb de CPUs utilisé est dans BinaryData.
Pour faire des essais, l'utilisation du trace flag 8687 désactive le
parallélisme pour une connexion. Ca vous permet de faire des essais avec
des appels de sp par exemple.
Vous pouvez également appeler
DBCC SQLPERF(WAITSTATS)
et regarder le nombre de waits de type CXPACKET, qui indiquent des
attentes
dûes au parallélisme (un processus qui attend la fin d'un de ses threads).
Si vous voyez en grand nombre, cela signifie qu'il y a eu beaucoup de
waits
de ce type depuis le lancement de SQL Server.
Ceci est lisible sur mon blog
http://www.babaluga.org/blog/archives/2005/03/30/max-degree-of-parallelism/
avec des liens sur d'autres ressources.
Si vos CPUs sont toujours à 100%, peut-être s'agit-il d'un autre problème,
par exemple un grand nombre de scans dû à des requêtes mal optimisées ou
un
manque d'index, ou simplement une trop grande charge du serveur.
--
Rudi Bruchez - MCDBA
http://www.babaluga.com/
Microsoft recommande carémment de désactiver l'hyperthreading sous Windows
2000 que ce soit avec SQL Server ou pour des sites web car l'OS ne le
supporte pas et vois donc ces performances s'écrouler.
--
arno - http://www.dotnetguru2.org/acleret/
"Rudi Bruchez" <"rudi#nospam#[at]babaluga.com"> a écrit dans le message de
news: 416npv99hdad$.xde9t7o0efnw$
> Christophe a écrit:
>
>> si je comprends bien nous avons un bi opteron
>> donc dans le systeme 4 cpu mais en vrai 2
>>
>> il faudrait mettre ???
>> EXEC sp_configure 'max degree of parallelism', 2
>> RECONFIGURE WITH OVERRIDE
>>
>> Toutefois la valeur actuelle est
>> 'max degree of parallelism' ,0, 32, 0, 0
>>
>> quand j'applique j'ai !
>> 'max degree of parallelism' ,0, 32, 2, 0
>>
>> comment ce comporte t'il ?
>> avec les 2 cpus sans hyperthreading ? ou 1 cpu + hyper ??
>>
>> Merci par avance !
>
> je vous avais donné quatre selon votre premier post où vous parliez de 4
> CPUs. Dans ce cas, c'est bien 2.
>
> en effet, vous êtes passé d'un maxdop à 0 (illimité) à 2. Avez-vous noté
> une différence de charge de CPU ? Sur un serveur que j'ai eu l'occasion
> d'administrer il y a qq mois, l'effet était presque immédiat.
>
> Pour le comportement, il ne devrait pas y avoir de problème de confusion
> avec SQL Server. Les deux CPUs physiques devraient être correctement
> utilisés. En cas de problème, vous pouvez essayer de descendre à 1, cad
> désactiver le parallélisme. Si votre serveur est très sollicité, le
> parallélisme n'est probablement pas utile.
>
> Qq petits trucs sur le parallélisme: vous pouvez tracer avec le profiler
> un
> des évènements de parallélisme dans les évènements de performance
> un seul de ces évènement est suffisant dans SQL 2000). Dans la colonne
> EventSubClass data vous trouverez le type de requête (select, update,.),
> le
> nb de CPUs utilisé est dans BinaryData.
>
> Pour faire des essais, l'utilisation du trace flag 8687 désactive le
> parallélisme pour une connexion. Ca vous permet de faire des essais avec
> des appels de sp par exemple.
>
> Vous pouvez également appeler
> DBCC SQLPERF(WAITSTATS)
> et regarder le nombre de waits de type CXPACKET, qui indiquent des
> attentes
> dûes au parallélisme (un processus qui attend la fin d'un de ses
> Si vous voyez en grand nombre, cela signifie qu'il y a eu beaucoup de
> waits
> de ce type depuis le lancement de SQL Server.
>
> Ceci est lisible sur mon blog
>
> avec des liens sur d'autres ressources.
>
> Si vos CPUs sont toujours à 100%, peut-être s'agit-il d'un autre
> par exemple un grand nombre de scans dû à des requêtes mal optimisées ou
> un
> manque d'index, ou simplement une trop grande charge du serveur.
>
> --
> Rudi Bruchez - MCDBA
> http://www.babaluga.com/
Microsoft recommande carémment de désactiver l'hyperthreading sous Windows
2000 que ce soit avec SQL Server ou pour des sites web car l'OS ne le
supporte pas et vois donc ces performances s'écrouler.
--
arno - http://www.dotnetguru2.org/acleret/
"Rudi Bruchez" <"rudi#nospam#[at]babaluga.com"> a écrit dans le message de
news: 416npv99hdad$.xde9t7o0efnw$.dlg@40tude.net...
> Christophe a écrit:
>
>> si je comprends bien nous avons un bi opteron
>> donc dans le systeme 4 cpu mais en vrai 2
>>
>> il faudrait mettre ???
>> EXEC sp_configure 'max degree of parallelism', 2
>> RECONFIGURE WITH OVERRIDE
>>
>> Toutefois la valeur actuelle est
>> 'max degree of parallelism' ,0, 32, 0, 0
>>
>> quand j'applique j'ai !
>> 'max degree of parallelism' ,0, 32, 2, 0
>>
>> comment ce comporte t'il ?
>> avec les 2 cpus sans hyperthreading ? ou 1 cpu + hyper ??
>>
>> Merci par avance !
>
> je vous avais donné quatre selon votre premier post où vous parliez de 4
> CPUs. Dans ce cas, c'est bien 2.
>
> en effet, vous êtes passé d'un maxdop à 0 (illimité) à 2. Avez-vous noté
> une différence de charge de CPU ? Sur un serveur que j'ai eu l'occasion
> d'administrer il y a qq mois, l'effet était presque immédiat.
>
> Pour le comportement, il ne devrait pas y avoir de problème de confusion
> avec SQL Server. Les deux CPUs physiques devraient être correctement
> utilisés. En cas de problème, vous pouvez essayer de descendre à 1, cad
> désactiver le parallélisme. Si votre serveur est très sollicité, le
> parallélisme n'est probablement pas utile.
>
> Qq petits trucs sur le parallélisme: vous pouvez tracer avec le profiler
> un
> des évènements de parallélisme dans les évènements de performance
> un seul de ces évènement est suffisant dans SQL 2000). Dans la colonne
> EventSubClass data vous trouverez le type de requête (select, update,.),
> le
> nb de CPUs utilisé est dans BinaryData.
>
> Pour faire des essais, l'utilisation du trace flag 8687 désactive le
> parallélisme pour une connexion. Ca vous permet de faire des essais avec
> des appels de sp par exemple.
>
> Vous pouvez également appeler
> DBCC SQLPERF(WAITSTATS)
> et regarder le nombre de waits de type CXPACKET, qui indiquent des
> attentes
> dûes au parallélisme (un processus qui attend la fin d'un de ses
> Si vous voyez en grand nombre, cela signifie qu'il y a eu beaucoup de
> waits
> de ce type depuis le lancement de SQL Server.
>
> Ceci est lisible sur mon blog
>
> avec des liens sur d'autres ressources.
>
> Si vos CPUs sont toujours à 100%, peut-être s'agit-il d'un autre
> par exemple un grand nombre de scans dû à des requêtes mal optimisées ou
> un
> manque d'index, ou simplement une trop grande charge du serveur.
>
> --
> Rudi Bruchez - MCDBA
> http://www.babaluga.com/
Microsoft recommande carémment de désactiver l'hyperthreading sous Windows
2000 que ce soit avec SQL Server ou pour des sites web car l'OS ne le
supporte pas et vois donc ces performances s'écrouler.
--
arno - http://www.dotnetguru2.org/acleret/
"Rudi Bruchez" <"rudi#nospam#[at]babaluga.com"> a écrit dans le message de
news: 416npv99hdad$.xde9t7o0efnw$
> Christophe a écrit:
>
>> si je comprends bien nous avons un bi opteron
>> donc dans le systeme 4 cpu mais en vrai 2
>>
>> il faudrait mettre ???
>> EXEC sp_configure 'max degree of parallelism', 2
>> RECONFIGURE WITH OVERRIDE
>>
>> Toutefois la valeur actuelle est
>> 'max degree of parallelism' ,0, 32, 0, 0
>>
>> quand j'applique j'ai !
>> 'max degree of parallelism' ,0, 32, 2, 0
>>
>> comment ce comporte t'il ?
>> avec les 2 cpus sans hyperthreading ? ou 1 cpu + hyper ??
>>
>> Merci par avance !
>
> je vous avais donné quatre selon votre premier post où vous parliez de 4
> CPUs. Dans ce cas, c'est bien 2.
>
> en effet, vous êtes passé d'un maxdop à 0 (illimité) à 2. Avez-vous noté
> une différence de charge de CPU ? Sur un serveur que j'ai eu l'occasion
> d'administrer il y a qq mois, l'effet était presque immédiat.
>
> Pour le comportement, il ne devrait pas y avoir de problème de confusion
> avec SQL Server. Les deux CPUs physiques devraient être correctement
> utilisés. En cas de problème, vous pouvez essayer de descendre à 1, cad
> désactiver le parallélisme. Si votre serveur est très sollicité, le
> parallélisme n'est probablement pas utile.
>
> Qq petits trucs sur le parallélisme: vous pouvez tracer avec le profiler
> un
> des évènements de parallélisme dans les évènements de performance
> un seul de ces évènement est suffisant dans SQL 2000). Dans la colonne
> EventSubClass data vous trouverez le type de requête (select, update,.),
> le
> nb de CPUs utilisé est dans BinaryData.
>
> Pour faire des essais, l'utilisation du trace flag 8687 désactive le
> parallélisme pour une connexion. Ca vous permet de faire des essais avec
> des appels de sp par exemple.
>
> Vous pouvez également appeler
> DBCC SQLPERF(WAITSTATS)
> et regarder le nombre de waits de type CXPACKET, qui indiquent des
> attentes
> dûes au parallélisme (un processus qui attend la fin d'un de ses
> Si vous voyez en grand nombre, cela signifie qu'il y a eu beaucoup de
> waits
> de ce type depuis le lancement de SQL Server.
>
> Ceci est lisible sur mon blog
>
> avec des liens sur d'autres ressources.
>
> Si vos CPUs sont toujours à 100%, peut-être s'agit-il d'un autre
> par exemple un grand nombre de scans dû à des requêtes mal optimisées ou
> un
> manque d'index, ou simplement une trop grande charge du serveur.
>
> --
> Rudi Bruchez - MCDBA
> http://www.babaluga.com/
