Discussion :

[6rose]

Bonjour,

J'ai donc un deux serveurs sous windows 2000 qui contiennent chacun un ASE 12.5. Sur l'un des serveurs j'ai installé un répli 12.1 qui réplique mes procédures stockées de manière asynchrones. Ceci implique que si une modif sur un des serveur est faite (par une procédure stockée), l'exécution de cette modif est répliqué sur l'autre serveur. Mon problème est que le fait que ces procédures soit asynchrones, les temps des répercutions des modifs est assez long. Auriez vous des conseils pour optimiser la répercusion des modifs, bref pour accèlérer l'exécution des procédures asynchrones.

Merci.

[Fabien Celaia]

Qu'entends-tu par "assez long" ?
si les deux serveurs sont locaux sur un LAN, le temps de latence devrait etre minime. Affiches-nous le contenu des colonnes origin_time et dest_cmommit_time de la table rs_lastcommit de la base de donnees cible.

[6rose]

Oui les deux serveurs sont sur un réseau local à 100Mbits donc de ce coté pas de PB.

Voici un peu plus de précisions sur les tests que je fais en attendant que j'envoie le contenu de la table rs_lastcommit(je recommence mon test).

Je récapitule :
-Deux serveurs A et B

A : primaire : ASE 12.5 et REPLI 12.1

B : secondaire : ASE 12.5

A et B possèdent la meme base applicative.

J'utilise les fonctions appliquées (procédures stockée) de A vers B
et les fonctions de demande de réplication de B vers A.

Lors de mon test j'exécute une procedure stockée qui insert une ligne dans la table TEST de la base primaire du serveur A. Cette procédure est répliquée (fonction appliquée) sur le serveur B et en même TEMPS j'exécute une procédure sur le serveur B qui insert aussi une ligne dans la table TEST et qui par une demande de réplication fais la modif sur le serveur A comme B.


Mon test simule 40 utilisateurs qui lancent chacun 100 fois 100 procédures d'insertion sur 100 tables. Bref à la fin j'obtients 100 tables contenant 4000 lignes chacunes.

Ces requètes arrivent à un répartiteur de charge réseau (load balancing de WIN2000). Il ya donc la moitiée des procédures qui arrivent sur le serveur A et l'autre sur le serveur B. La réplication s'exécutant, j'obtient bien les deux serveurs avec chacun 100 tables de 4000 lignes chacunes.


Sinon j'ai été obligé de bidouiller avec des procédures vides pour pouvoir utiliser des procédures avec le même nom.

Pour l'instant quand j'exécute mon test sur mon benchmark l'exécution se fait en 2 ou 3 minutes(temps identique à un test monoserveur) mais comme c'est asynchrone, il faut attendre environ 1 heure et oui j'ai bien dit 1 heure pour que toutes les modifs soient exécutées.

C'est long vous trouvez pas :

[6rose]

tient un petit warning dans les logs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
W. 2003/08/29 15:03:07. WARNING #6089 SQM(108:0 sql00000.ASPTT) - (1589)
	WARNING: Stable Storage Use is Above 75 percent
W. 2003/08/29 15:04:24. WARNING #6091 DSI(108 sql00000.ASPTT) - (1607)
	WARNING CANCEL: Stable Storage Use is Below 75 percent

est-ce grave?

sinon le contenu de la table rs_last commit en plein milieu de mon test:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
 origin_time                dest_commit_time
 -------------------------- --------------------------
        Jan  1 1900 12:00AM        Aug 29 2003  9:23AM
        Aug 29 2003  2:47PM        Aug 29 2003  3:10PM

à environ 3000 insertion sur 4000


j'ai l'impression que c'est assez rapide pour les premières insertions et qu'après ca se ralenti sérieusement.

voilà

j'enverrai aussi ce contenu à la fin de mon test

[6rose]

et voici le contenu de rs_lastcommit à la fin de mon test:

origin_time dest_commit_time
-------------------------- --------------------------
Jan 1 1900 12:00AM Aug 29 2003 9:23AM
Aug 29 2003 3:38PM Aug 29 2003 3:37PM

[Fabien Celaia]

Une latence de 23 minutes, c'est effectivement pas court.
Quelle est la taille de ton stable device ?
As-tu essayé de marquer les procédures stockées comme répliquées ?
Autre petite question : pourquoi RS 12.1 dans un environement ASE12.5 ? Pourquoi pas utiliser RS 12.5 ?

Utilises-tu des updates massifs ? Sais-tu qu'un update massif touchant 1000 lignes sur la base source est transformé en 1000 updates d'une ligne sur la cible (d'où certains problèmes de verrouillage par manque de structures locks sur le cible) ?

[6rose]

Alors mon stable device est à 200.
Sinon pour les versions de ASE et de REPLI j'ai pris ce qu'il y avait de disponible dans l'entreprise où je suis.
Toutes mes procédures sont marquées comme répliquées.
Lors de mon test il y avait juste des procédures d'insert d'une ligne à chaque fois.
Ce temps de latence est donc bien anormal :

[Fabien Celaia]

Ce temps de latence est donc bien anormal :

En environement local ? Non, ca ne me semble pas normal comme temps de latence. Tu fais quoi ? des inserts ou updates massifs ?

Dans ce cas, garde a l'esprit qu'un update de 10000 lignes sous l'ASE source genere 10000 updates d'une ligne sous l'ASE source (hormis si tu passes via une SP repliquee)

[6rose]

Oui je suis bien en local et je fais des inserts, updates et deletes massifs mais avec des sp répliquées.

[Fabien Celaia]

Donc, ce temps de latence est donc bien anormal. Quel est ta taille de paquets par defaut ? et ton parametre TCP no delay ?

[6rose]

si c'est bien ce que tu demandes , voici les paramètres de mon fichier .cfg de mon moteur ASE hébergeant le RSSD:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
default network packet size = 1024
max network packet size = 2048
tcp no delay = DEFAULT

je n'ai pas modifier le paramètre "tcp no delay"

[6rose]

voilà un extrait de mon fichier sql.ini pour mon moteur hébregeant la RSSD (base primaire).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
sql00000]
master=NLWNSCK,203.45.130.139,4100 
query=NLWNSCK,203.45.130.139,4100 
master=TCP,110.1.1.1,4300
query=TCP,110.1.1.1,4300

Est ce que le fait d'utiliser 2 protocoles différents pourrait être la cause de mes soucis? Quelle est la différence entre ces 2 protocoles?

[Fabien Celaia]

Commence par passer tcp no delay a 1. C'est historique ce 0...

En ce qui concerne le fichier d'interface, si la bonne adresse est celle d'en-bas, la connexion peut etre tres longue... et peut etre la cause de ton probleme.

[6rose]

alors le paramètre 'tcp no delay' était bien à 1
c'est la valeur par défaut

en ce qui concerne le fichier sql.ini

oui c'est bien la ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
query=TCP,110.1.1.1,4300

qui est utilisé par le moteur de réplication pour accèder au moteur ASE primaire (sql00000)

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
query=TCP,110.1.1.2,4400

pour le moteur ASE secondaire(sql00001)

j'ai essayé de changer le protocole mais ca n'a rien changé.

mes deux serveurs sont reliés par un cable croisé pour la réplication (110.1.1.1 et 110.1.1.2).

sinon pourquoi la connexion peut elle être très longue :