J'essaie de trouver des solutions à un problème de performance sur un
serveur SQL 2005 :
Topo.
- Windows Server 2003 Entreprise, 4x Dual Core, 16 GB RAM, Cluster
Actif-Passif.
- SQL Server 2005 Entreprise SP2, AWE, SQL Max Memory 13 GB
- Buffer SQL ok : Buffer cache hit ratio 99,8+
- Il n'y a pas de /PAE, mais c'est du hardware Hot Swappable, il selon la
doc MS, pas besoin de /PAE sur ce type de materiel.
Le problème vient de procédures lourdes, très longues à compiler. Cela
produit un grand nombre de locks de compilation. Cela tient certainement à
la qualité du code SQL, l'utilisation de beaucoup de vues imbriquées, des
grosses tables, beaucoup d'index à choisir... Bref des choses à optimiser.
Je ne vois pas passer dans le profiler d'update automatique de
statistiques, donc ce n’est pas le problème.
Par contre en situation de stress, ça compile souvent. Apparemment le cache
de procédure (syscacheobjects) est vidé régulièrement, il semble donc y
avoir de la pression sur la mémoire. Ca ressemble bien à ceci :
C’est très problématique en cas de grosse charge... mais je ne vois pas de
moyen d'éviter ça, et j'ai l'impression d’avoir épuisé les options de
config.
Il me reste à tenter /3GB pour augmenter le working set pour SQL, il semble
que ce soit ok jusqu'à 16gb. Je note que le cache de procédure n'est pas
géré dans AWE, seul le buffer l'est.
Quand la charge n’est pas trop importante, pas de vidage notable du cache.
Les CPUs sont presque toujours en-dessus de 90%
Qqn a-t-il déjà rencontré le problème, ou a une idée à laquelle je n'aurais
pas pensé ?
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
Pas de problème de surparallèlisation? Pas trop de changement de contexte (passer en mode fiber) Que dit le page fault? Si le cpu est très haut, peut etre un pb d'UDF sur utilisées, que disent les traces?
br
"Rudi Bruchez" <rudi#nospam#at#babaluga.com> wrote in message news:
Bonjour,
J'essaie de trouver des solutions à un problème de performance sur un serveur SQL 2005 :
Topo. - Windows Server 2003 Entreprise, 4x Dual Core, 16 GB RAM, Cluster Actif-Passif. - SQL Server 2005 Entreprise SP2, AWE, SQL Max Memory 13 GB - Buffer SQL ok : Buffer cache hit ratio 99,8+ - Il n'y a pas de /PAE, mais c'est du hardware Hot Swappable, il selon la doc MS, pas besoin de /PAE sur ce type de materiel.
Le problème vient de procédures lourdes, très longues à compiler. Cela produit un grand nombre de locks de compilation. Cela tient certainement à la qualité du code SQL, l'utilisation de beaucoup de vues imbriquées, des grosses tables, beaucoup d'index à choisir... Bref des choses à optimiser. Je ne vois pas passer dans le profiler d'update automatique de statistiques, donc ce n’est pas le problème.
Par contre en situation de stress, ça compile souvent. Apparemment le cache de procédure (syscacheobjects) est vidé régulièrement, il semble donc y avoir de la pression sur la mémoire. Ca ressemble bien à ceci :
C’est très problématique en cas de grosse charge... mais je ne vois pas de moyen d'éviter ça, et j'ai l'impression d’avoir épuisé les options de config.
Il me reste à tenter /3GB pour augmenter le working set pour SQL, il semble que ce soit ok jusqu'à 16gb. Je note que le cache de procédure n'est pas géré dans AWE, seul le buffer l'est.
Quand la charge n’est pas trop importante, pas de vidage notable du cache. Les CPUs sont presque toujours en-dessus de 90%
Qqn a-t-il déjà rencontré le problème, ou a une idée à laquelle je n'aurais pas pensé ?
Pas de problème de surparallèlisation?
Pas trop de changement de contexte (passer en mode fiber)
Que dit le page fault?
Si le cpu est très haut, peut etre un pb d'UDF sur utilisées, que disent les
traces?
br
"Rudi Bruchez" <rudi#nospam#at#babaluga.com> wrote in message
news:93xq0ov5ve7p.1dehf7w3sk2q9.dlg@40tude.net...
Bonjour,
J'essaie de trouver des solutions à un problème de performance sur un
serveur SQL 2005 :
Topo.
- Windows Server 2003 Entreprise, 4x Dual Core, 16 GB RAM, Cluster
Actif-Passif.
- SQL Server 2005 Entreprise SP2, AWE, SQL Max Memory 13 GB
- Buffer SQL ok : Buffer cache hit ratio 99,8+
- Il n'y a pas de /PAE, mais c'est du hardware Hot Swappable, il selon la
doc MS, pas besoin de /PAE sur ce type de materiel.
Le problème vient de procédures lourdes, très longues à compiler. Cela
produit un grand nombre de locks de compilation. Cela tient certainement à
la qualité du code SQL, l'utilisation de beaucoup de vues imbriquées, des
grosses tables, beaucoup d'index à choisir... Bref des choses à optimiser.
Je ne vois pas passer dans le profiler d'update automatique de
statistiques, donc ce n’est pas le problème.
Par contre en situation de stress, ça compile souvent. Apparemment le
cache
de procédure (syscacheobjects) est vidé régulièrement, il semble donc y
avoir de la pression sur la mémoire. Ca ressemble bien à ceci :
C’est très problématique en cas de grosse charge... mais je ne vois pas de
moyen d'éviter ça, et j'ai l'impression d’avoir épuisé les options de
config.
Il me reste à tenter /3GB pour augmenter le working set pour SQL, il
semble
que ce soit ok jusqu'à 16gb. Je note que le cache de procédure n'est pas
géré dans AWE, seul le buffer l'est.
Quand la charge n’est pas trop importante, pas de vidage notable du cache.
Les CPUs sont presque toujours en-dessus de 90%
Qqn a-t-il déjà rencontré le problème, ou a une idée à laquelle je
n'aurais
pas pensé ?
Pas de problème de surparallèlisation? Pas trop de changement de contexte (passer en mode fiber) Que dit le page fault? Si le cpu est très haut, peut etre un pb d'UDF sur utilisées, que disent les traces?
br
"Rudi Bruchez" <rudi#nospam#at#babaluga.com> wrote in message news:
Bonjour,
J'essaie de trouver des solutions à un problème de performance sur un serveur SQL 2005 :
Topo. - Windows Server 2003 Entreprise, 4x Dual Core, 16 GB RAM, Cluster Actif-Passif. - SQL Server 2005 Entreprise SP2, AWE, SQL Max Memory 13 GB - Buffer SQL ok : Buffer cache hit ratio 99,8+ - Il n'y a pas de /PAE, mais c'est du hardware Hot Swappable, il selon la doc MS, pas besoin de /PAE sur ce type de materiel.
Le problème vient de procédures lourdes, très longues à compiler. Cela produit un grand nombre de locks de compilation. Cela tient certainement à la qualité du code SQL, l'utilisation de beaucoup de vues imbriquées, des grosses tables, beaucoup d'index à choisir... Bref des choses à optimiser. Je ne vois pas passer dans le profiler d'update automatique de statistiques, donc ce n’est pas le problème.
Par contre en situation de stress, ça compile souvent. Apparemment le cache de procédure (syscacheobjects) est vidé régulièrement, il semble donc y avoir de la pression sur la mémoire. Ca ressemble bien à ceci :
C’est très problématique en cas de grosse charge... mais je ne vois pas de moyen d'éviter ça, et j'ai l'impression d’avoir épuisé les options de config.
Il me reste à tenter /3GB pour augmenter le working set pour SQL, il semble que ce soit ok jusqu'à 16gb. Je note que le cache de procédure n'est pas géré dans AWE, seul le buffer l'est.
Quand la charge n’est pas trop importante, pas de vidage notable du cache. Les CPUs sont presque toujours en-dessus de 90%
Qqn a-t-il déjà rencontré le problème, ou a une idée à laquelle je n'aurais pas pensé ?
est-ce que les noms d'objets incluent bien le nom de schema?
br
"Rudi Bruchez" <rudi#nospam#at#babaluga.com> wrote in message news:
Bonjour,
J'essaie de trouver des solutions à un problème de performance sur un serveur SQL 2005 :
Topo. - Windows Server 2003 Entreprise, 4x Dual Core, 16 GB RAM, Cluster Actif-Passif. - SQL Server 2005 Entreprise SP2, AWE, SQL Max Memory 13 GB - Buffer SQL ok : Buffer cache hit ratio 99,8+ - Il n'y a pas de /PAE, mais c'est du hardware Hot Swappable, il selon la doc MS, pas besoin de /PAE sur ce type de materiel.
Le problème vient de procédures lourdes, très longues à compiler. Cela produit un grand nombre de locks de compilation. Cela tient certainement à la qualité du code SQL, l'utilisation de beaucoup de vues imbriquées, des grosses tables, beaucoup d'index à choisir... Bref des choses à optimiser. Je ne vois pas passer dans le profiler d'update automatique de statistiques, donc ce n’est pas le problème.
Par contre en situation de stress, ça compile souvent. Apparemment le cache de procédure (syscacheobjects) est vidé régulièrement, il semble donc y avoir de la pression sur la mémoire. Ca ressemble bien à ceci :
C’est très problématique en cas de grosse charge... mais je ne vois pas de moyen d'éviter ça, et j'ai l'impression d’avoir épuisé les options de config.
Il me reste à tenter /3GB pour augmenter le working set pour SQL, il semble que ce soit ok jusqu'à 16gb. Je note que le cache de procédure n'est pas géré dans AWE, seul le buffer l'est.
Quand la charge n’est pas trop importante, pas de vidage notable du cache. Les CPUs sont presque toujours en-dessus de 90%
Qqn a-t-il déjà rencontré le problème, ou a une idée à laquelle je n'aurais pas pensé ?
est-ce que les noms d'objets incluent bien le nom de schema?
br
"Rudi Bruchez" <rudi#nospam#at#babaluga.com> wrote in message
news:93xq0ov5ve7p.1dehf7w3sk2q9.dlg@40tude.net...
Bonjour,
J'essaie de trouver des solutions à un problème de performance sur un
serveur SQL 2005 :
Topo.
- Windows Server 2003 Entreprise, 4x Dual Core, 16 GB RAM, Cluster
Actif-Passif.
- SQL Server 2005 Entreprise SP2, AWE, SQL Max Memory 13 GB
- Buffer SQL ok : Buffer cache hit ratio 99,8+
- Il n'y a pas de /PAE, mais c'est du hardware Hot Swappable, il selon la
doc MS, pas besoin de /PAE sur ce type de materiel.
Le problème vient de procédures lourdes, très longues à compiler. Cela
produit un grand nombre de locks de compilation. Cela tient certainement à
la qualité du code SQL, l'utilisation de beaucoup de vues imbriquées, des
grosses tables, beaucoup d'index à choisir... Bref des choses à optimiser.
Je ne vois pas passer dans le profiler d'update automatique de
statistiques, donc ce n’est pas le problème.
Par contre en situation de stress, ça compile souvent. Apparemment le
cache
de procédure (syscacheobjects) est vidé régulièrement, il semble donc y
avoir de la pression sur la mémoire. Ca ressemble bien à ceci :
C’est très problématique en cas de grosse charge... mais je ne vois pas de
moyen d'éviter ça, et j'ai l'impression d’avoir épuisé les options de
config.
Il me reste à tenter /3GB pour augmenter le working set pour SQL, il
semble
que ce soit ok jusqu'à 16gb. Je note que le cache de procédure n'est pas
géré dans AWE, seul le buffer l'est.
Quand la charge n’est pas trop importante, pas de vidage notable du cache.
Les CPUs sont presque toujours en-dessus de 90%
Qqn a-t-il déjà rencontré le problème, ou a une idée à laquelle je
n'aurais
pas pensé ?
est-ce que les noms d'objets incluent bien le nom de schema?
br
"Rudi Bruchez" <rudi#nospam#at#babaluga.com> wrote in message news:
Bonjour,
J'essaie de trouver des solutions à un problème de performance sur un serveur SQL 2005 :
Topo. - Windows Server 2003 Entreprise, 4x Dual Core, 16 GB RAM, Cluster Actif-Passif. - SQL Server 2005 Entreprise SP2, AWE, SQL Max Memory 13 GB - Buffer SQL ok : Buffer cache hit ratio 99,8+ - Il n'y a pas de /PAE, mais c'est du hardware Hot Swappable, il selon la doc MS, pas besoin de /PAE sur ce type de materiel.
Le problème vient de procédures lourdes, très longues à compiler. Cela produit un grand nombre de locks de compilation. Cela tient certainement à la qualité du code SQL, l'utilisation de beaucoup de vues imbriquées, des grosses tables, beaucoup d'index à choisir... Bref des choses à optimiser. Je ne vois pas passer dans le profiler d'update automatique de statistiques, donc ce n’est pas le problème.
Par contre en situation de stress, ça compile souvent. Apparemment le cache de procédure (syscacheobjects) est vidé régulièrement, il semble donc y avoir de la pression sur la mémoire. Ca ressemble bien à ceci :
C’est très problématique en cas de grosse charge... mais je ne vois pas de moyen d'éviter ça, et j'ai l'impression d’avoir épuisé les options de config.
Il me reste à tenter /3GB pour augmenter le working set pour SQL, il semble que ce soit ok jusqu'à 16gb. Je note que le cache de procédure n'est pas géré dans AWE, seul le buffer l'est.
Quand la charge n’est pas trop importante, pas de vidage notable du cache. Les CPUs sont presque toujours en-dessus de 90%
Qqn a-t-il déjà rencontré le problème, ou a une idée à laquelle je n'aurais pas pensé ?
On Fri, 13 Jul 2007 10:50:57 -0300, bruno reiter wrote:
Pas de problème de surparallèlisation? Pas trop de changement de contexte (passer en mode fiber) Que dit le page fault? Si le cpu est très haut, peut etre un pb d'UDF sur utilisées, que disent les traces?
Bonjour Bruno,
Merci pour tes pistes. Pour la parallélisation, j'étais déjà passé en maxdop 1, Il y avait des UDF dans les SELECT, mais le principal problème était la taille de certains plans d'exécution, et surtout le manque de mémoire de travail. Cela vidait le cache de procédures quand la machine était sous pression. Le /3GB y a remédié.
On Fri, 13 Jul 2007 10:50:57 -0300, bruno reiter wrote:
Pas de problème de surparallèlisation?
Pas trop de changement de contexte (passer en mode fiber)
Que dit le page fault?
Si le cpu est très haut, peut etre un pb d'UDF sur utilisées, que disent les
traces?
Bonjour Bruno,
Merci pour tes pistes. Pour la parallélisation, j'étais déjà passé en
maxdop 1, Il y avait des UDF dans les SELECT, mais le principal problème
était la taille de certains plans d'exécution, et surtout le manque de
mémoire de travail. Cela vidait le cache de procédures quand la machine
était sous pression. Le /3GB y a remédié.
On Fri, 13 Jul 2007 10:50:57 -0300, bruno reiter wrote:
Pas de problème de surparallèlisation? Pas trop de changement de contexte (passer en mode fiber) Que dit le page fault? Si le cpu est très haut, peut etre un pb d'UDF sur utilisées, que disent les traces?
Bonjour Bruno,
Merci pour tes pistes. Pour la parallélisation, j'étais déjà passé en maxdop 1, Il y avait des UDF dans les SELECT, mais le principal problème était la taille de certains plans d'exécution, et surtout le manque de mémoire de travail. Cela vidait le cache de procédures quand la machine était sous pression. Le /3GB y a remédié.
