je manage un serveur w2k2003 2GO ram/RAID 10 mono proc avec un serveur sql
2000.
Il y a dessus une base de donnée de 4GO sur laquelle se connectnt une
cinquantaine de clients lourd windows.
Certain traitements (appelant des procédures stockées en cascades et
englobées dans une transaction générale), font monter le taux d'occupation
CPU à 100%
ce qui bloque alors le travail de tous les autres user en attendan tla fin
du traitement et le commit et donc la redégringolade de l'occupation
procésseur à 1%.
Je me demande si, (hormis le fait d'un tunning de la Base de donnée et/ou de
sa ré-écriture....), on pourrais immaginer un deuxième serveur clône du
premier avec une base de donnée identique (réplication, database mororing
???).
En temps normal les connexions utilisateurs se répartiraient entre les deux
serveurs et , si jamais l'un monte à 100% d'occupation CPU, alors toutes les
nouvelles connexions seraient redirigées de façon transparente pour
l'utilisateur vers le deuxième serveur en attendant que le premier
redevienne disponible et soit synchronisé.
En fait j'imagine donc un type d'équilibrage de charge entre serveur sql
différent tournant sur du hardware séparé et des données séparées mais
synchronisées.
(Je précise bien que je ne recherche pas de solution de failover mais bien
une solution pour que l'ensemble des utilisateurs ne soient pas bloqués
quand un processus lourd monopolise toutes les ressources de mon serveur)
A) est-ce que c'est possible ?
B) si oui, la SNCF :-) ou Microsoft l'a t il fait ?
C) cela est il possible sans toucher au code de l'application lourde qui
n'est pas de notre responsabilité ? mais juste avec cette architecture
client/serveur spéciale ?
Merci d'avance de vos avis.
Je suis en phase d'investissement à court terme et l'achat d'un seule
serveur musclé ou de deux clônes représentent des alternatives que je doit
trancher très vite.
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
Fred.M.
Bonjour Laurent, Le genre de serveur clône que tu décris sont plutôt destinés à des scenarii de disaster recovery (appelés aussi serveurs StandBy). A ta problématique de disponibilité des requêtes, plusieurs solutions se profilent: - Faire l'acquision d'un MultiProc afin de paralléliser les requêtes. - Mettre ton 2ème serveur en Clustering (attention à la version de ton OS 2003). - Cela étant dit, si le problème vient du temps d'exécution au sein d'une transaction, je crains que ces changements d'archi physiques ne soient pas forcément la solution miracle (un verrou ça restera un verrou !). Je t'invite par conséquent à faire un audit sur les accès concurrents au sein de ta base (objets lockés, type de verrous, niveau d'escalade des verrous...) et voire au niveau de ton intégrateur s'il est possible d'implémenter l'option "Set Transaction Isolation Level Read Uncommitted".
Fred M. (DBA SNCF, si si c'est possible :) ).
"Laurent" a écrit :
Bonjour à tous,
je manage un serveur w2k2003 2GO ram/RAID 10 mono proc avec un serveur sql 2000. Il y a dessus une base de donnée de 4GO sur laquelle se connectnt une cinquantaine de clients lourd windows.
Certain traitements (appelant des procédures stockées en cascades et englobées dans une transaction générale), font monter le taux d'occupation CPU à 100% ce qui bloque alors le travail de tous les autres user en attendan tla fin du traitement et le commit et donc la redégringolade de l'occupation procésseur à 1%.
Je me demande si, (hormis le fait d'un tunning de la Base de donnée et/ou de sa ré-écriture....), on pourrais immaginer un deuxième serveur clône du premier avec une base de donnée identique (réplication, database mororing ???).
En temps normal les connexions utilisateurs se répartiraient entre les deux serveurs et , si jamais l'un monte à 100% d'occupation CPU, alors toutes les nouvelles connexions seraient redirigées de façon transparente pour l'utilisateur vers le deuxième serveur en attendant que le premier redevienne disponible et soit synchronisé.
En fait j'imagine donc un type d'équilibrage de charge entre serveur sql différent tournant sur du hardware séparé et des données séparées mais synchronisées. (Je précise bien que je ne recherche pas de solution de failover mais bien une solution pour que l'ensemble des utilisateurs ne soient pas bloqués quand un processus lourd monopolise toutes les ressources de mon serveur)
A) est-ce que c'est possible ?
B) si oui, la SNCF :-) ou Microsoft l'a t il fait ?
C) cela est il possible sans toucher au code de l'application lourde qui n'est pas de notre responsabilité ? mais juste avec cette architecture client/serveur spéciale ?
Merci d'avance de vos avis. Je suis en phase d'investissement à court terme et l'achat d'un seule serveur musclé ou de deux clônes représentent des alternatives que je doit trancher très vite.
Laurent
Bonjour Laurent,
Le genre de serveur clône que tu décris sont plutôt destinés à des scenarii
de disaster recovery (appelés aussi serveurs StandBy). A ta problématique de
disponibilité des requêtes, plusieurs solutions se profilent:
- Faire l'acquision d'un MultiProc afin de paralléliser les requêtes.
- Mettre ton 2ème serveur en Clustering (attention à la version de ton OS
2003).
- Cela étant dit, si le problème vient du temps d'exécution au sein d'une
transaction, je crains que ces changements d'archi physiques ne soient pas
forcément la solution miracle (un verrou ça restera un verrou !). Je t'invite
par conséquent à faire un audit sur les accès concurrents au sein de ta base
(objets lockés, type de verrous, niveau d'escalade des verrous...) et voire
au niveau de ton intégrateur s'il est possible d'implémenter l'option "Set
Transaction Isolation Level Read Uncommitted".
Fred M. (DBA SNCF, si si c'est possible :) ).
"Laurent" a écrit :
Bonjour à tous,
je manage un serveur w2k2003 2GO ram/RAID 10 mono proc avec un serveur sql
2000. Il y a dessus une base de donnée de 4GO sur laquelle se connectnt une
cinquantaine de clients lourd windows.
Certain traitements (appelant des procédures stockées en cascades et
englobées dans une transaction générale), font monter le taux d'occupation
CPU à 100%
ce qui bloque alors le travail de tous les autres user en attendan tla fin
du traitement et le commit et donc la redégringolade de l'occupation
procésseur à 1%.
Je me demande si, (hormis le fait d'un tunning de la Base de donnée et/ou de
sa ré-écriture....), on pourrais immaginer un deuxième serveur clône du
premier avec une base de donnée identique (réplication, database mororing
???).
En temps normal les connexions utilisateurs se répartiraient entre les deux
serveurs et , si jamais l'un monte à 100% d'occupation CPU, alors toutes les
nouvelles connexions seraient redirigées de façon transparente pour
l'utilisateur vers le deuxième serveur en attendant que le premier
redevienne disponible et soit synchronisé.
En fait j'imagine donc un type d'équilibrage de charge entre serveur sql
différent tournant sur du hardware séparé et des données séparées mais
synchronisées.
(Je précise bien que je ne recherche pas de solution de failover mais bien
une solution pour que l'ensemble des utilisateurs ne soient pas bloqués
quand un processus lourd monopolise toutes les ressources de mon serveur)
A) est-ce que c'est possible ?
B) si oui, la SNCF :-) ou Microsoft l'a t il fait ?
C) cela est il possible sans toucher au code de l'application lourde qui
n'est pas de notre responsabilité ? mais juste avec cette architecture
client/serveur spéciale ?
Merci d'avance de vos avis.
Je suis en phase d'investissement à court terme et l'achat d'un seule
serveur musclé ou de deux clônes représentent des alternatives que je doit
trancher très vite.
Bonjour Laurent, Le genre de serveur clône que tu décris sont plutôt destinés à des scenarii de disaster recovery (appelés aussi serveurs StandBy). A ta problématique de disponibilité des requêtes, plusieurs solutions se profilent: - Faire l'acquision d'un MultiProc afin de paralléliser les requêtes. - Mettre ton 2ème serveur en Clustering (attention à la version de ton OS 2003). - Cela étant dit, si le problème vient du temps d'exécution au sein d'une transaction, je crains que ces changements d'archi physiques ne soient pas forcément la solution miracle (un verrou ça restera un verrou !). Je t'invite par conséquent à faire un audit sur les accès concurrents au sein de ta base (objets lockés, type de verrous, niveau d'escalade des verrous...) et voire au niveau de ton intégrateur s'il est possible d'implémenter l'option "Set Transaction Isolation Level Read Uncommitted".
Fred M. (DBA SNCF, si si c'est possible :) ).
"Laurent" a écrit :
Bonjour à tous,
je manage un serveur w2k2003 2GO ram/RAID 10 mono proc avec un serveur sql 2000. Il y a dessus une base de donnée de 4GO sur laquelle se connectnt une cinquantaine de clients lourd windows.
Certain traitements (appelant des procédures stockées en cascades et englobées dans une transaction générale), font monter le taux d'occupation CPU à 100% ce qui bloque alors le travail de tous les autres user en attendan tla fin du traitement et le commit et donc la redégringolade de l'occupation procésseur à 1%.
Je me demande si, (hormis le fait d'un tunning de la Base de donnée et/ou de sa ré-écriture....), on pourrais immaginer un deuxième serveur clône du premier avec une base de donnée identique (réplication, database mororing ???).
En temps normal les connexions utilisateurs se répartiraient entre les deux serveurs et , si jamais l'un monte à 100% d'occupation CPU, alors toutes les nouvelles connexions seraient redirigées de façon transparente pour l'utilisateur vers le deuxième serveur en attendant que le premier redevienne disponible et soit synchronisé.
En fait j'imagine donc un type d'équilibrage de charge entre serveur sql différent tournant sur du hardware séparé et des données séparées mais synchronisées. (Je précise bien que je ne recherche pas de solution de failover mais bien une solution pour que l'ensemble des utilisateurs ne soient pas bloqués quand un processus lourd monopolise toutes les ressources de mon serveur)
A) est-ce que c'est possible ?
B) si oui, la SNCF :-) ou Microsoft l'a t il fait ?
C) cela est il possible sans toucher au code de l'application lourde qui n'est pas de notre responsabilité ? mais juste avec cette architecture client/serveur spéciale ?
Merci d'avance de vos avis. Je suis en phase d'investissement à court terme et l'achat d'un seule serveur musclé ou de deux clônes représentent des alternatives que je doit trancher très vite.
Laurent
Fred BROUARD
Laurent a écrit :
Bonjour à tous,
je manage un serveur w2k2003 2GO ram/RAID 10 mono proc avec un serveur sql 2000.
Il y a dessus une base de donnée de 4GO sur laquelle se connectnt une cinquantaine de clients lourd windows.
Certain traitements (appelant des procédures stockées en cascades et englobées dans une transaction générale), font monter le taux d'occupation CPU à 100%
normal, SQL Server est optimisé pour tirer partie, de la totalité des ressources lorsqu'il en ressent le besoin.
ce qui bloque alors le travail de tous les autres user en attendan tla fin du traitement et le commit et donc la redégringolade de l'occupation procésseur à 1%.
Mauvaise parallélisation. plusieurs possibilité pour y remèdier : 1) descendre le niveau d'isolation de certaines transactins 2) ajouter du CPU et éviter la parralélisation en jouant sur le paramètres MAXDOP (à différent niveau : serveur, requête...) ...
Je me demande si, (hormis le fait d'un tunning de la Base de donnée et/ou de sa ré-écriture....), on pourrais immaginer un deuxième serveur clône du premier avec une base de donnée identique (réplication, database mororing ???).
La réplication rajoute du process donc pénalise encore plus les performances et nécessite plus d'admin. Avant de faire du scale out on fait du scale up.
En temps normal les connexions utilisateurs se répartiraient entre les deux serveurs et , si jamais l'un monte à 100% d'occupation CPU, alors toutes les nouvelles connexions seraient redirigées de façon transparente pour l'utilisateur vers le deuxième serveur en attendant que le premier redevienne disponible et soit synchronisé.
en théorie !
En fait j'imagine donc un type d'équilibrage de charge entre serveur sql différent tournant sur du hardware séparé et des données séparées mais synchronisées. (Je précise bien que je ne recherche pas de solution de failover mais bien une solution pour que l'ensemble des utilisateurs ne soient pas bloqués quand un processus lourd monopolise toutes les ressources de mon serveur)
A) est-ce que c'est possible ?
Oui en cluster, mais bonjour le coût ! Coût d'acquisition du matériel, car nécessite du matériel approuvé + coût des licences + coût d'administration...
B) si oui, la SNCF :-) ou Microsoft l'a t il fait ?
C) cela est il possible sans toucher au code de l'application lourde qui n'est pas de notre responsabilité ? mais juste avec cette architecture client/serveur spéciale ?
Le mieux serait d'auditer le code applicatif... Quand même ! Si l'application n'a pas été écrite correctement, vous aurez beau faire tout ce que vous voulez le problème sera toujours là !
Merci d'avance de vos avis. Je suis en phase d'investissement à court terme et l'achat d'un seule serveur musclé ou de deux clônes représentent des alternatives que je doit trancher très vite.
Donc multi processeur au moins 2 CPU, mais mieux vaut 4 que hyper threading car d'autres problèmes existent dans le multi threading d'intel
Laurent
A +
-- 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 ***********************
Laurent a écrit :
Bonjour à tous,
je manage un serveur w2k2003 2GO ram/RAID 10 mono proc avec un serveur sql
2000.
Il y a dessus une base de donnée de 4GO sur laquelle se connectnt une
cinquantaine de clients lourd windows.
Certain traitements (appelant des procédures stockées en cascades et
englobées dans une transaction générale), font monter le taux d'occupation
CPU à 100%
normal, SQL Server est optimisé pour tirer partie, de la totalité des
ressources lorsqu'il en ressent le besoin.
ce qui bloque alors le travail de tous les autres user en attendan tla fin
du traitement et le commit et donc la redégringolade de l'occupation
procésseur à 1%.
Mauvaise parallélisation.
plusieurs possibilité pour y remèdier :
1) descendre le niveau d'isolation de certaines transactins
2) ajouter du CPU et éviter la parralélisation en jouant sur le
paramètres MAXDOP (à différent niveau : serveur, requête...)
...
Je me demande si, (hormis le fait d'un tunning de la Base de donnée et/ou de
sa ré-écriture....), on pourrais immaginer un deuxième serveur clône du
premier avec une base de donnée identique (réplication, database mororing
???).
La réplication rajoute du process donc pénalise encore plus les
performances et nécessite plus d'admin. Avant de faire du scale out on
fait du scale up.
En temps normal les connexions utilisateurs se répartiraient entre les deux
serveurs et , si jamais l'un monte à 100% d'occupation CPU, alors toutes les
nouvelles connexions seraient redirigées de façon transparente pour
l'utilisateur vers le deuxième serveur en attendant que le premier
redevienne disponible et soit synchronisé.
en théorie !
En fait j'imagine donc un type d'équilibrage de charge entre serveur sql
différent tournant sur du hardware séparé et des données séparées mais
synchronisées.
(Je précise bien que je ne recherche pas de solution de failover mais bien
une solution pour que l'ensemble des utilisateurs ne soient pas bloqués
quand un processus lourd monopolise toutes les ressources de mon serveur)
A) est-ce que c'est possible ?
Oui en cluster, mais bonjour le coût ! Coût d'acquisition du matériel,
car nécessite du matériel approuvé + coût des licences + coût
d'administration...
B) si oui, la SNCF :-) ou Microsoft l'a t il fait ?
C) cela est il possible sans toucher au code de l'application lourde qui
n'est pas de notre responsabilité ? mais juste avec cette architecture
client/serveur spéciale ?
Le mieux serait d'auditer le code applicatif... Quand même ! Si
l'application n'a pas été écrite correctement, vous aurez beau faire
tout ce que vous voulez le problème sera toujours là !
Merci d'avance de vos avis.
Je suis en phase d'investissement à court terme et l'achat d'un seule
serveur musclé ou de deux clônes représentent des alternatives que je doit
trancher très vite.
Donc multi processeur au moins 2 CPU, mais mieux vaut 4 que hyper
threading car d'autres problèmes existent dans le multi threading d'intel
Laurent
A +
--
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 ***********************
je manage un serveur w2k2003 2GO ram/RAID 10 mono proc avec un serveur sql 2000.
Il y a dessus une base de donnée de 4GO sur laquelle se connectnt une cinquantaine de clients lourd windows.
Certain traitements (appelant des procédures stockées en cascades et englobées dans une transaction générale), font monter le taux d'occupation CPU à 100%
normal, SQL Server est optimisé pour tirer partie, de la totalité des ressources lorsqu'il en ressent le besoin.
ce qui bloque alors le travail de tous les autres user en attendan tla fin du traitement et le commit et donc la redégringolade de l'occupation procésseur à 1%.
Mauvaise parallélisation. plusieurs possibilité pour y remèdier : 1) descendre le niveau d'isolation de certaines transactins 2) ajouter du CPU et éviter la parralélisation en jouant sur le paramètres MAXDOP (à différent niveau : serveur, requête...) ...
Je me demande si, (hormis le fait d'un tunning de la Base de donnée et/ou de sa ré-écriture....), on pourrais immaginer un deuxième serveur clône du premier avec une base de donnée identique (réplication, database mororing ???).
La réplication rajoute du process donc pénalise encore plus les performances et nécessite plus d'admin. Avant de faire du scale out on fait du scale up.
En temps normal les connexions utilisateurs se répartiraient entre les deux serveurs et , si jamais l'un monte à 100% d'occupation CPU, alors toutes les nouvelles connexions seraient redirigées de façon transparente pour l'utilisateur vers le deuxième serveur en attendant que le premier redevienne disponible et soit synchronisé.
en théorie !
En fait j'imagine donc un type d'équilibrage de charge entre serveur sql différent tournant sur du hardware séparé et des données séparées mais synchronisées. (Je précise bien que je ne recherche pas de solution de failover mais bien une solution pour que l'ensemble des utilisateurs ne soient pas bloqués quand un processus lourd monopolise toutes les ressources de mon serveur)
A) est-ce que c'est possible ?
Oui en cluster, mais bonjour le coût ! Coût d'acquisition du matériel, car nécessite du matériel approuvé + coût des licences + coût d'administration...
B) si oui, la SNCF :-) ou Microsoft l'a t il fait ?
C) cela est il possible sans toucher au code de l'application lourde qui n'est pas de notre responsabilité ? mais juste avec cette architecture client/serveur spéciale ?
Le mieux serait d'auditer le code applicatif... Quand même ! Si l'application n'a pas été écrite correctement, vous aurez beau faire tout ce que vous voulez le problème sera toujours là !
Merci d'avance de vos avis. Je suis en phase d'investissement à court terme et l'achat d'un seule serveur musclé ou de deux clônes représentent des alternatives que je doit trancher très vite.
Donc multi processeur au moins 2 CPU, mais mieux vaut 4 que hyper threading car d'autres problèmes existent dans le multi threading d'intel
Laurent
A +
-- 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 ***********************
