J'ai plusieurs centaines de serveur qui chaque matin se connectent =E0
un serveur SQL pour y =E9crire des informations syst=E8me (une sorte de
collecte). Chaque collecte est en fait une s=E9rie de petites
insertions, pouvant aller jusqu'a 30 insertions.
Le probl=E8me est qu'ils collectent tous =E0 la m=EAme heure; =E7a je ne
peux pas le changer, j'ai tent=E9 de ruser avec une insertion retard=E9e
de qques secondes al=E9atoire (rand) pour Chacune d'elles(les
insertions), et donc il fallait le pr=E9voir, j'ai quand m=EAme des
deadlock !!, c-a-d que quand un process fait son ou ses insertion(s),
le ou les autre(s) se font 'tuer' (en fait c'est un peu plus compliqu=E9
que =E7a) mais le r=E9sultat est le m=EAme.
Voil=E0 si quelqu'un a une piste ou carr=E9ment la solution :) , je suis
preneur.
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
Arnaud CLERET
Attention les deadlock ne sont pas la résultante d'une activité trop grande mais d'un mauvais agencement de vos requêtes. L'exemple suivant engendre un deadlock : CREATE PROCEDURE One CREATE PROCEDURE Two
AS AS
UPDATE TABLE_A SET ... UPDATE TABLE_B SET ...
UPDATE TABLE_B SET ... UPDATE TABLE_A SET ...
GO GO
D'autre part, le fait d'avoir 30 * 200 serveurs ne fait que 6000 requêtes ce qui suivant votre configuration matérielle ne représente pas un nombre très important de transaction à la seconde. De plus, la charge augmentant c'est le temps d'exécution de chacune des requêtes qui s'allonge et non des deadlock qui se produisent. -- arno - http://www.dotnetguru2.org/acleret/
"Alextophi" a écrit dans le message de news:
bonjour
J'expose mon problème:
J'ai plusieurs centaines de serveur qui chaque matin se connectent à un serveur SQL pour y écrire des informations système (une sorte de collecte). Chaque collecte est en fait une série de petites insertions, pouvant aller jusqu'a 30 insertions.
Le problème est qu'ils collectent tous à la même heure; ça je ne peux pas le changer, j'ai tenté de ruser avec une insertion retardée de qques secondes aléatoire (rand) pour Chacune d'elles(les insertions), et donc il fallait le prévoir, j'ai quand même des deadlock !!, c-a-d que quand un process fait son ou ses insertion(s), le ou les autre(s) se font 'tuer' (en fait c'est un peu plus compliqué que ça) mais le résultat est le même.
Voilà si quelqu'un a une piste ou carrément la solution :) , je suis preneur.
Merci à tous
Christophe
Attention les deadlock ne sont pas la résultante d'une activité trop grande
mais d'un mauvais agencement de vos requêtes. L'exemple suivant engendre un
deadlock :
CREATE PROCEDURE One CREATE PROCEDURE Two
AS AS
UPDATE TABLE_A SET ... UPDATE TABLE_B SET ...
UPDATE TABLE_B SET ... UPDATE TABLE_A SET ...
GO GO
D'autre part, le fait d'avoir 30 * 200 serveurs ne fait que 6000 requêtes ce
qui suivant votre configuration matérielle ne représente pas un nombre très
important de transaction à la seconde. De plus, la charge augmentant c'est
le temps d'exécution de chacune des requêtes qui s'allonge et non des
deadlock qui se produisent.
--
arno - http://www.dotnetguru2.org/acleret/
"Alextophi" <ext.astek.brakha@sncf.fr> a écrit dans le message de news:
1147161664.682254.32630@u72g2000cwu.googlegroups.com...
bonjour
J'expose mon problème:
J'ai plusieurs centaines de serveur qui chaque matin se connectent à
un serveur SQL pour y écrire des informations système (une sorte de
collecte). Chaque collecte est en fait une série de petites
insertions, pouvant aller jusqu'a 30 insertions.
Le problème est qu'ils collectent tous à la même heure; ça je ne
peux pas le changer, j'ai tenté de ruser avec une insertion retardée
de qques secondes aléatoire (rand) pour Chacune d'elles(les
insertions), et donc il fallait le prévoir, j'ai quand même des
deadlock !!, c-a-d que quand un process fait son ou ses insertion(s),
le ou les autre(s) se font 'tuer' (en fait c'est un peu plus compliqué
que ça) mais le résultat est le même.
Voilà si quelqu'un a une piste ou carrément la solution :) , je suis
preneur.
Attention les deadlock ne sont pas la résultante d'une activité trop grande mais d'un mauvais agencement de vos requêtes. L'exemple suivant engendre un deadlock : CREATE PROCEDURE One CREATE PROCEDURE Two
AS AS
UPDATE TABLE_A SET ... UPDATE TABLE_B SET ...
UPDATE TABLE_B SET ... UPDATE TABLE_A SET ...
GO GO
D'autre part, le fait d'avoir 30 * 200 serveurs ne fait que 6000 requêtes ce qui suivant votre configuration matérielle ne représente pas un nombre très important de transaction à la seconde. De plus, la charge augmentant c'est le temps d'exécution de chacune des requêtes qui s'allonge et non des deadlock qui se produisent. -- arno - http://www.dotnetguru2.org/acleret/
"Alextophi" a écrit dans le message de news:
bonjour
J'expose mon problème:
J'ai plusieurs centaines de serveur qui chaque matin se connectent à un serveur SQL pour y écrire des informations système (une sorte de collecte). Chaque collecte est en fait une série de petites insertions, pouvant aller jusqu'a 30 insertions.
Le problème est qu'ils collectent tous à la même heure; ça je ne peux pas le changer, j'ai tenté de ruser avec une insertion retardée de qques secondes aléatoire (rand) pour Chacune d'elles(les insertions), et donc il fallait le prévoir, j'ai quand même des deadlock !!, c-a-d que quand un process fait son ou ses insertion(s), le ou les autre(s) se font 'tuer' (en fait c'est un peu plus compliqué que ça) mais le résultat est le même.
Voilà si quelqu'un a une piste ou carrément la solution :) , je suis preneur.
