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 ?
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.
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 ?
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.
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 ?
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.
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.
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.
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 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 enRaid10 ? (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 ***********************
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 ***********************
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 enRaid10 ? (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 ***********************
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" a écrit dans le message de n ews:
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 -
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" <broua...@club-internet.fr> a écrit dans le message de n ews:
Og$f7xKtHHA.4...@TK2MSFTNGP05.phx.gbl...
>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 -
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" a écrit dans le message de n ews:
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 -
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" a écrit dans le message de
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 -
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" <broua...@club-internet.fr> a écrit dans le message de
news:
Og$f7xKtHHA.4...@TK2MSFTNGP05.phx.gbl...
>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 -
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" a écrit dans le message de
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 -