SQL Serveur 2005 et performances

Le
L C
Bonjour
Je cherche optimiser au maximum les performances de mon serveur.
J'ai une base de 40Go pour l'instant qui est sur un SAN de 200Go en raid5.
J'ai 3,5Go de RAM et 2 CPU 3,6Ghz Hyperthread.
Je suis souvent a 99% de CPU.

Y-A-T-il un document résumant les bonnes pratiques ?
Dois-je passer au 64bits ? Dois-je mettre 20Go de RAM ? Dois-je passer en
Raid10 ? (cela m'ennuirai un peu)

Car ma base sera à l'avenir beaucoup plus sollicitée et surtout beaucoup
plus grosse (+de 100go)

Merci de votre aide.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fred BROUARD
Le #11855431
L C a écrit :
Bonjour
Je cherche optimiser au maximum les performances de mon serveur.
J'ai une base de 40Go pour l'instant qui est sur un SAN de 200Go en raid5.
J'ai 3,5Go de RAM et 2 CPU 3,6Ghz Hyperthread.
Je suis souvent a 99% de CPU.



1) évitez l'hyper threading. En effet celui-ci est bugué et intel ne
peut pas produire de correctif. De plus l'apport mesuré de l'HT est de
l'ordre de 15% dans les meilleurs cas.
Lire : http://www.zdnet.co.uk/tsearch/server+problems.htm


2) les san(s) ne sont intéressant pour des SGBDR que s'ils sont
hautement administrables si vous vous abstenez de faire du zoning et
créez des LUN correspondant à des agrégats physique.
Si votre san est utilisé par d'autres serveur, si vous n'avez pas fait
de découpage par disque, etc... alors pas de perf.
les performances s'obtiennent avec deux conditions SINEQUANONES :
a) faire différents aggrégats raid correspondants à des disques physiques
2) avoir dimensionné vos fichiers de base de données en taille fixe en
estimant la taille à terme.

Exemple : SAN 12 disques :
1 : RAID 1 sur 2 disques => OS, exécutables SQL Server, pagaefile.sys
2 : RAID 1 sur 2 disques => tempdb
3 : RAID 1 sur 2 disques => journaux de transaction de la base de prod
4 : RAID 5 sur 3 disques => données de la base de prod
2 : RAID 1 sur 3 disques => index de la base de prod

Et en ayant soin de dimensionner les différents fichiers de votre base
avec la volumétrie estimée par exemple à 3 ans, sachant que :
l'indexation devrait représenter de 30 à 40 % de plus que les données
le JT peut être taillé à 1/3 du volume globale de la base (data + index)


Y-A-T-il un document résumant les bonnes pratiques ?



Quelque centaines....

Dois-je passer au 64bits ?



N'a d'intérêt que si vous faite massivement du SELECt et très peu de
mise à jour (cas des bases OLAP)

Dois-je mettre 20Go de RAM ?

Tout dépend de la fenêtre des données.


Dois-je passer en
Raid10 ? (cela m'ennuirai un peu)



Pas sûr tout dépend de ce que vous voulez favoriser :
soit les SELECT
soit les mise à jour (DELETE INSERT UPDATE)

Bref, tout cela s'audite et ne se fait pas à la légère !



Car ma base sera à l'avenir beaucoup plus sollicitée et surtout beaucoup
plus grosse (+de 100go)

Merci de votre aide.






PS : l'indication de votre CPU chargé ne signifie généralement pas qu'il
faut en rajouter. Il faut creuser pourquoi il s'agite tant...

--
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 ***********************
lionelp
Le #11855371
Bonjour,

Si la CPU est en moyenne à 80% ou au-delà on conseille d'upgrader le serveur.
S'il y a un doc pour suivre les performances d'un serveur SQL Server 2005
c'est:
http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
L'intérêt de passer en 64bit (x64) est que l'on s'affranchit des contraintes
32bit (la mémoire conventionelle est restreinte à 2GB-3GB), seule la cache
donnée bénéficie de la mémoire au-delà des 4GB, et il y a beaucoup d'autres
choses qui ont besoin de cache. Certains mécanismes de régulation de
compilations de requêtes sont moins contraignants en 64bit qu'en 32bit.
La mémoire nécessaire, là on ne peut pas deviner. Mais un système 64bit
commence vers les 8GB de RAM de base.
On conseille le raid10 mais le coût est non négligeable, d'ailleurs il
semble que ce soit le stockage qui coute le plus. Alors si le raid5 offre de
bonne perfs et une bonne sécurité, on peut toujours le changer plus tard.
Ce qui est dit sur l'hyperthreading est à prendre avec des pincettes, Slava
disait dans son blog "ça dépend" :
"So does it mean you have to disable HT when using SQL Server? The answer is
it really depends on the load and hardware you are using. "
On voit maintenant arriver des systèmes quadri-core, les discussions sur
l'hyper-threading et de ses risques sont obsolètes. En revanche, choisir un
système qui a déjà reçu des révisions de bios et firmware c'est bien.

Cordialement,
LionelP
"L C" a écrit :

Bonjour
Je cherche optimiser au maximum les performances de mon serveur.
J'ai une base de 40Go pour l'instant qui est sur un SAN de 200Go en raid5.
J'ai 3,5Go de RAM et 2 CPU 3,6Ghz Hyperthread.
Je suis souvent a 99% de CPU.

Y-A-T-il un document résumant les bonnes pratiques ?
Dois-je passer au 64bits ? Dois-je mettre 20Go de RAM ? Dois-je passer en
Raid10 ? (cela m'ennuirai un peu)

Car ma base sera à l'avenir beaucoup plus sollicitée et surtout beaucoup
plus grosse (+de 100go)

Merci de votre aide.






L C
Le #11855211
Merci beaucoup pour votre réponse.
Nous allons donc isoler les logs, les tempDB et les indexes

par contre vous avez dit RAID1 (Mirroring)? Vous vouliez peut etre dire
RAID0?
Ce n'est pas dangereux si un disque qui gere mon index lache ?

merci

"Fred BROUARD" Og$
L C a écrit :
Bonjour
Je cherche optimiser au maximum les performances de mon serveur.
J'ai une base de 40Go pour l'instant qui est sur un SAN de 200Go en
raid5.
J'ai 3,5Go de RAM et 2 CPU 3,6Ghz Hyperthread.
Je suis souvent a 99% de CPU.



1) évitez l'hyper threading. En effet celui-ci est bugué et intel ne peut
pas produire de correctif. De plus l'apport mesuré de l'HT est de l'ordre
de 15% dans les meilleurs cas.
Lire : http://www.zdnet.co.uk/tsearch/server+problems.htm


2) les san(s) ne sont intéressant pour des SGBDR que s'ils sont hautement
administrables si vous vous abstenez de faire du zoning et créez des LUN
correspondant à des agrégats physique.
Si votre san est utilisé par d'autres serveur, si vous n'avez pas fait de
découpage par disque, etc... alors pas de perf.
les performances s'obtiennent avec deux conditions SINEQUANONES :
a) faire différents aggrégats raid correspondants à des disques physiques
2) avoir dimensionné vos fichiers de base de données en taille fixe en
estimant la taille à terme.

Exemple : SAN 12 disques :
1 : RAID 1 sur 2 disques => OS, exécutables SQL Server, pagaefile.sys
2 : RAID 1 sur 2 disques => tempdb
3 : RAID 1 sur 2 disques => journaux de transaction de la base de prod
4 : RAID 5 sur 3 disques => données de la base de prod
2 : RAID 1 sur 3 disques => index de la base de prod

Et en ayant soin de dimensionner les différents fichiers de votre base
avec la volumétrie estimée par exemple à 3 ans, sachant que :
l'indexation devrait représenter de 30 à 40 % de plus que les données
le JT peut être taillé à 1/3 du volume globale de la base (data + index)


Y-A-T-il un document résumant les bonnes pratiques ?



Quelque centaines....

Dois-je passer au 64bits ?



N'a d'intérêt que si vous faite massivement du SELECt et très peu de mise
à jour (cas des bases OLAP)

Dois-je mettre 20Go de RAM ?

Tout dépend de la fenêtre des données.


Dois-je passer en
Raid10 ? (cela m'ennuirai un peu)



Pas sûr tout dépend de ce que vous voulez favoriser :
soit les SELECT
soit les mise à jour (DELETE INSERT UPDATE)

Bref, tout cela s'audite et ne se fait pas à la légère !



Car ma base sera à l'avenir beaucoup plus sollicitée et surtout beaucoup
plus grosse (+de 100go)

Merci de votre aide.






PS : l'indication de votre CPU chargé ne signifie généralement pas qu'il
faut en rajouter. Il faut creuser pourquoi il s'agite tant...

--
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 ***********************


SQLpro
Le #11855081
On 26 juin, 11:48, "L C"
Merci beaucoup pour votre réponse.
Nous allons donc isoler les logs, les tempDB et les indexes

par contre vous avez dit RAID1 (Mirroring)? Vous vouliez peut etre dire
RAID0?



Non, bien RAID 1 cad mirroring et non RAID 0 stripping.

A +

Ce n'est pas dangereux si un disque qui gere mon index lache ?

merci

"Fred BROUARD" Og$



>L C a écrit :
>> Bonjour
>> Je cherche optimiser au maximum les performances de mon serveur.
>> J'ai une base de 40Go pour l'instant qui est sur un SAN de 200Go en
>> raid5.
>> J'ai 3,5Go de RAM et 2 CPU 3,6Ghz Hyperthread.
>> Je suis souvent a 99% de CPU.

> 1) évitez l'hyper threading. En effet celui-ci est bugué et intel n e peut
> pas produire de correctif. De plus l'apport mesuré de l'HT est de l'o rdre
> de 15% dans les meilleurs cas.
> Lire :http://www.zdnet.co.uk/tsearch/server+problems.htm

> 2) les san(s) ne sont intéressant pour des SGBDR que s'ils sont haute ment
> administrables si vous vous abstenez de faire du zoning et créez des LUN
> correspondant à des agrégats physique.
> Si votre san est utilisé par d'autres serveur, si vous n'avez pas fai t de
> découpage par disque, etc... alors pas de perf.
> les performances s'obtiennent avec deux conditions SINEQUANONES :
> a) faire différents aggrégats raid correspondants à des disques p hysiques
> 2) avoir dimensionné vos fichiers de base de données en taille fixe en
> estimant la taille à terme.

> Exemple : SAN 12 disques :
> 1 : RAID 1 sur 2 disques => OS, exécutables SQL Server, pagaefile.s ys
> 2 : RAID 1 sur 2 disques => tempdb
> 3 : RAID 1 sur 2 disques => journaux de transaction de la base de prod
> 4 : RAID 5 sur 3 disques => données de la base de prod
> 2 : RAID 1 sur 3 disques => index de la base de prod

> Et en ayant soin de dimensionner les différents fichiers de votre base
> avec la volumétrie estimée par exemple à 3 ans, sachant que :
> l'indexation devrait représenter de 30 à 40 % de plus que les donn ées
> le JT peut être taillé à 1/3 du volume globale de la base (data + index)

>> Y-A-T-il un document résumant les bonnes pratiques ?

> Quelque centaines....

>> Dois-je passer au 64bits ?

> N'a d'intérêt que si vous faite massivement du SELECt et très peu de mise
> à jour (cas des bases OLAP)

> Dois-je mettre 20Go de RAM ?

> Tout dépend de la fenêtre des données.

> Dois-je passer en
>> Raid10 ? (cela m'ennuirai un peu)

> Pas sûr tout dépend de ce que vous voulez favoriser :
> soit les SELECT
> soit les mise à jour (DELETE INSERT UPDATE)

> Bref, tout cela s'audite et ne se fait pas à la légère !

>> Car ma base sera à l'avenir beaucoup plus sollicitée et surtout be aucoup
>> plus grosse (+de 100go)

>> Merci de votre aide.

> PS : l'indication de votre CPU chargé ne signifie généralement pa s qu'il
> faut en rajouter. Il faut creuser pourquoi il s'agite tant...

> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et lang age SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisat ion
> *********************http://www.datasapiens.com***********************- Masquer le texte des messages précédents -

- Afficher le texte des messages précédents -


L C
Le #11854981
D'accord.

Car dans votre exemple vous avez mis 3 disques en RAID 1 pour les indexes.

Cela augmente la tolérence de panne ainsi que le temps d'acces et de
lecture/ecriture?

J'en aurais mis 4 en RAID 10.

"SQLpro"
On 26 juin, 11:48, "L C"
Merci beaucoup pour votre réponse.
Nous allons donc isoler les logs, les tempDB et les indexes

par contre vous avez dit RAID1 (Mirroring)? Vous vouliez peut etre dire
RAID0?



Non, bien RAID 1 cad mirroring et non RAID 0 stripping.

A +

Ce n'est pas dangereux si un disque qui gere mon index lache ?

merci

"Fred BROUARD" news:
Og$



>L C a écrit :
>> Bonjour
>> Je cherche optimiser au maximum les performances de mon serveur.
>> J'ai une base de 40Go pour l'instant qui est sur un SAN de 200Go en
>> raid5.
>> J'ai 3,5Go de RAM et 2 CPU 3,6Ghz Hyperthread.
>> Je suis souvent a 99% de CPU.

> 1) évitez l'hyper threading. En effet celui-ci est bugué et intel ne
> peut
> pas produire de correctif. De plus l'apport mesuré de l'HT est de
> l'ordre
> de 15% dans les meilleurs cas.
> Lire :http://www.zdnet.co.uk/tsearch/server+problems.htm

> 2) les san(s) ne sont intéressant pour des SGBDR que s'ils sont
> hautement
> administrables si vous vous abstenez de faire du zoning et créez des LUN
> correspondant à des agrégats physique.
> Si votre san est utilisé par d'autres serveur, si vous n'avez pas fait
> de
> découpage par disque, etc... alors pas de perf.
> les performances s'obtiennent avec deux conditions SINEQUANONES :
> a) faire différents aggrégats raid correspondants à des disques
> physiques
> 2) avoir dimensionné vos fichiers de base de données en taille fixe en
> estimant la taille à terme.

> Exemple : SAN 12 disques :
> 1 : RAID 1 sur 2 disques => OS, exécutables SQL Server, pagaefile.sys
> 2 : RAID 1 sur 2 disques => tempdb
> 3 : RAID 1 sur 2 disques => journaux de transaction de la base de prod
> 4 : RAID 5 sur 3 disques => données de la base de prod
> 2 : RAID 1 sur 3 disques => index de la base de prod

> Et en ayant soin de dimensionner les différents fichiers de votre base
> avec la volumétrie estimée par exemple à 3 ans, sachant que :
> l'indexation devrait représenter de 30 à 40 % de plus que les données
> le JT peut être taillé à 1/3 du volume globale de la base (data + index)

>> Y-A-T-il un document résumant les bonnes pratiques ?

> Quelque centaines....

>> Dois-je passer au 64bits ?

> N'a d'intérêt que si vous faite massivement du SELECt et très peu de
> mise
> à jour (cas des bases OLAP)

> Dois-je mettre 20Go de RAM ?

> Tout dépend de la fenêtre des données.

> Dois-je passer en
>> Raid10 ? (cela m'ennuirai un peu)

> Pas sûr tout dépend de ce que vous voulez favoriser :
> soit les SELECT
> soit les mise à jour (DELETE INSERT UPDATE)

> Bref, tout cela s'audite et ne se fait pas à la légère !

>> Car ma base sera à l'avenir beaucoup plus sollicitée et surtout
>> beaucoup
>> plus grosse (+de 100go)

>> Merci de votre aide.

> PS : l'indication de votre CPU chargé ne signifie généralement pas qu'il
> faut en rajouter. Il faut creuser pourquoi il s'agite tant...

> --
> 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***********************-
> Masquer le texte des messages précédents -

- Afficher le texte des messages précédents -


Publicité
Poster une réponse
Anonyme