> Tech > Où se produisent les goulets d’étranglement

Où se produisent les goulets d’étranglement

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Les Snapshot et Distribution Agents exécutent leurs tâches d'après le design, mais un petit nombre d'entre elles peuvent causer d'importants goulets d'étranglement nuisibles à  la performance. Evaluons la performance des agents en appliquant un jeu de mesures standard.

Définir les critères de performances. Pour évaluer le temps d'exécution d'une application,

Où se produisent les goulets d’étranglement

on peut mesurer
son exécution par des moyens
empiriques ou évaluer mathématiquement
son algorithme. Dans cette section,
je me livre à  une mesure
empirique et à  une évaluation mathématique
des étapes des agents pour
comparer les résultats de ces deux méthodes.
Pour chiffrer le temps d’exécution
mathématiquement, on représente
le temps d’exécution de
l’algorithme par l’ordre de grandeur d’augmentation du temps quand le volume
des données entrées augmente.
Cette tendance croissante du temps
d’exécution montre la capacité d’un algorithme
à  évoluer avec la charge. Par
exemple, si le temps nécessaire pour
traiter des données de taille n augmente
en parallèle avec la taille des
données (par exemple s’il faut 2 secondes
pour traiter 1 000 enregistrements
et s’il en faut 20 pour en traiter
10 000), le temps d’exécution de l’algorithme
croît en parallèle (en ordre linéaire)
de la taille des données. Cette
tendance croissante comme une fonction
de la taille des données est appelée
la complexité temps de l’algorithme
et est exprimée sous la forme
O(n) (ou ordre n) pour la complexité
temps en ordre linéaire. Un algorithme
qui finit toujours par une quantité de
temps constante indépendamment de
la quantité de données entrée, a une
complexité temps constante, que j’exprime
par O(c).

A présent, utilisons ces formules
pour évaluer la performance du
Snapshot Agent. Quel que soit le
nombre d’abonnements dans lesquels
vous devez copier des données, snapshot.
exe ne s’exécute qu’une fois pour
chaque publication à  chaque temps
programmé. La génération de fichiers
script .sch et .idx dans cette commande
prend un temps constant
(complexité O(c)), indépendant du
nombre d’enregistrements (exprimé
par n) dans la publication. Le temps
qu’il faut à  snapshot.exe pour générer
les fichiers .bcp est cependant directement
proportionnel à  la taille de la publication
(complexité temps O(n)). Ma
mesure empirique portant sur une publication
de 500 Mo de 6 millions d’enregistrements
montre que ce snapshot.
exe prend 7 secondes pour
générer les fichiers .sch et .idx, mais
prend 2 minutes et 38 secondes pour
générer des fichiers .bcp. Ces résultats
confirment que la vitesse de génération
des fichiers .bcp dépend de la
taille de la publication. Par rapport à  la
commande de Distribution Agent (distrib.exe), que j’évalue ensuite, la
commande du Snapshot Agent
(snapshot.exe) est encore très rapide,
même pour générer de grands fichiers
.bcp. Aucun goulet d’étranglement ne
nuit à  sa performance.

Comme le Snapshot Agent ne ralentit
pas le processus de réplication
snapshot, le Distribution Agent doit
être le coupable. En appliquant les formules
aux étapes de cet agent, on voit
où se produisent les goulets d’étranglement.

Premier goulet d’étranglement :
supprimer les enregistrements cible.

Distrib.exe s’exécute une fois pour
chaque abonnement. Elle fait exactement
le contraire de snapshot.exe : elle applique (dans l’ordre) tous les fichiers
.sch, .bcp et .idx d’une publication à 
une base de données d’abonnements
cible. Ce faisant, la commande assume
le fardeau représenté par la journalisation
de toutes les instructions DELETE
dans l’étape sch et de l’indexation de
toutes les tables cible dans l’étape idx.
Une instruction DELETE dans l’étape
sch par défaut supprime tous les
enregistrements (en supposant qu’aucun
filtre n’ait été spécifié) dans la
table cible ; ce processus a une complexité
de O(n), où n est le nombre
d’enregistrements dans la table cible.
En outre, chaque suppression enregistre
chaque ligne supprimée dans
le journal de transactions et supprime
la ligne correspondante des
arbres B d’index groupés (clustered)
et non groupés (non clustered).
D’après le plan d’exécution de la figure
9, l’instruction DELETE copie
chaque ligne dans tempdb (Table
Spool) une fois pour chaque index
non clustered et supprime chaque
ligne de chaque arbre B d’index.
Chaque copie ou suppression dans
ce plan d’exécution coûte environ 10
% du coût total de l’instruction DELETE.
Par conséquent, pour une
table avec m index, chaque index
contribue à  environ 1/m du coût de
traitement total. La complexité globale
de l’instruction DELETE dans l’étape
sch est donc O(m x n). Dans l’exemple
fourni précédemment (avec un serveur
de développement à  4 CPU – avec
1 Go de RAM et RAID 5 – pour traiter
une publication de 500 Mo avec 6 millions
d’enregistrements), la durée classique
pour supprimer tous les enregistrements
dans les tables cible est de 58
minutes. On voit donc que le fait de
supprimer les enregistrements cible
crée un goulet d’étranglement qui
grandit avec la taille et le nombre
d’index d’une publication.

Second goulet d’étranglement :
copier en masse les données source.

Après l’étape sch, l’étape bcp insère en
masse tous les enregistrements des
fichiers .bcp dans des tables cible indexées respectives. On peut régler
l’exécution d’un Distribution Agent en
définissant des paramètres dans son
profil. (Pour accéder au profil, faites un
clic droit sur un Distribution Agent –
CGIS1:pubs dans le panneau droit de
la figure 2 – puis sélectionnez Agent
Profile.) Par exemple, le fait d’élever la
valeur de BcpBatchSize (le nombre
d’enregistrements copiés par batch
bcp) dans le profil peut réduire la journalisation
de l’historique de distribution.
On peut aussi ajuster la valeur de
MaxBcpThreads (le nombre de threads
bcp simultanés dans l’étape bcp) pour
correspondre au nombre de CPU sur le
serveur de distribution. Toutefois, je
n’ai pas jugé le profil utile pour améliorer
la performance et l’évolutivité
pendant la distribution de mes données
de test. De plus, il manque à  distrib.
exe un paramètre bcp utile – le ORDER
hint. Quand on le définit, le ORDER hint ordonne à  bcp de trier les
données d’après l’index en cluster
(éventuel) sur la table cible avant de
copier les données dans celle-ci. En
fait, les données sont répliquées dans
l’ordre d’index en cluster, et les enregistrements
copiés par la suite n’amènent
jamais SQL Server à  imposer
l’ordre d’index en cluster par le réagencement
des enregistrements antérieurs.
Par conséquent, le bcp « ordered
» est nettement plus rapide que
l’opération consistant à  renoncer à  l’index
en cluster avant et à  le recréer
après un bcp « unordered ».

Evaluons mathématiquement le meilleur scénario possible pour l’étape
bcp en supposant la présence du ORDER
hint. L’étape bcp dans ce scénario
consiste essentiellement à  insérer n
enregistrements triés (c’est-à -dire des
enregistrements ordonnés par l’index
clustered) dans chaque table cible et à 
insérer chaque ligne des colonnes indexées
de cette table dans chacun des
m arbres B d’index (en supposant que
m index existent). La complexité est
O(m x n) + O(n x log(n)) où O(n x
log(n)) est une time complexity classique
de trier et O(m x n) est la time
complexity d’insérer n enregistrements
et de maintenir m index pour chacun des n enregistrements insérés.
Rappelons que ceci est la time complexity
du meilleur scénario pour
l’étape bcp. En utilisant l’exemple précédent
d’une publication de 6 millions
d’enregistrements à  500 Mo, fonctionnant
sur un serveur de développement
à  4 CPU avec 1 Go de RAM et RAID 5,
l’étape bcp prend 55 minutes, soit
presque le même temps que l’étape
sch. Ce résultat confirme la similitude
de complexité entre les étapes sch et
bcp. Comme l’étape sch, l’étape bcp
crée un goulet d’étranglement qui s’aggrave
avec la taille et le nombre d’index
de la publication.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010