Discussion :

[jeeps64]

Bonjour

Je travaille actuellement sur des problemes de performances assez généraux.
En effet, nous avons constaté à plusieurs reprises, que le passage en mode DOL de table APL sur lesquelles on fait des mise à jour massives, a diminué les temps de traitement pas 2, 3 voir 4.

Nous avons fait des tests sur des bcp et update massifs.
J'ai des temps et des sysmons de ces tests si ca peut aider.

Je voulais donc savoir si quelqu'un peut expliquer un tel ecart ou m'expliquer les mecanismes des mise a jour DOL et APL.
SYBASE soupçonne un nombre d'io synchrone (Page split, Last Log Page Write, OAM Page Write...) plus important dans le cas APL mais sans pouvoir l'expliquer ou le montrer.

Je sais que c'est très général mais je suis ouvert à toute idée

Merci d'avance

Jeeps64

[mpeppler]

De quelle version d'ASE s'agit-il?

Aussi - est-ce que les tables APL ont des indexes "clustered" lors des inserts?
Si c'est le cas il se pourrait qu'il y ai une plus forte proportion de split de page si l'index clustered n'est pas dans le même ordre que les inserts...

Michael

[jeeps64]

Bonjour

Mes tests portent sur la version 12.5.3 ESD6 et 15.0.2 ESD2
Nous espérions en faisant les memes tests sur la 15.0.2 gagnait du temps sur les split de pages justement mais ca n'a pas était concluant.
En effet, en 15.0.2 une nouvelle fonctionnalité fait que le page split se fait de facon asynchrone (d'ou l'esperance d'un gain)

Nos tables ont la plupart du temps un index cluster et plusieurs indexes composites.
Pour info, nous avons relevé une forte proportion de split de pages en APL et en DOL. Par contre, dans "Task Context Switches Due To:" des différents sysmon réalisés, nous avons constaté ceci :
- en APL, nous avions autant de "System Disk Writes" que de "Page Splits" (section "Index Management") : environ 160000
- en DOL, ce même paramêtre "System Disk Writes" est quasiment nul alors que nous avons 150000 Page Splits

La section "System Disk Writes" contient le nombre de fois qu'une opération à attendu la fin d'une io synchrone (processes sleep during writes for page splits, recovery, and OAM page writes)

On dirait qu'en APL, il fait un Page Splits de facon synchrone alors qu'en DOL non ??? Comprend pas !!

Je sais pas si j'ai été clair mais n'hesites pas a me demander sinon

Merci en tout cas de tes remarques

Jeeps64

[mpeppler]

Je n'ai pas vraiment d'information supplémentaires à ajouter - il ne me semble pas qu'ASE utilise des stratégies d'IO différentes pour les splits de page en mode DOL vs. APL, mais peut-être que je me trompe.

Peut-être qu'une analyse détaillée des tables MDA (en particulier monSysWaits, monOpenObjectActivity) pourrait donner plus d'info?

Michael

[jeeps64]

Bonjour

Merci pour ces infos
En regardant ces tables MDA, on arrive pas non plus a expliquer concretement la fiddérence de comportement
En effet, nous avons mis en place ASEMONLOGGER (développé par JP MARTIN) qui collecte ces tables. cet outil ne nous donne pas vraiment d'explication non plus.

Je continue a chercher

Merci encore des idées Michael

jeeps64

[mpeppler]

Dans le cas particulier je pense qu'il faudrait faire une analyse détaillée des temps d'attentes via monProcessWaits ou éventuellement monSysWaits, et voir où les attentes sont les plus significatives.

Mais je suis d'accord que c'est assez bizarre.

Michael

[Roller]

Bonjour

Je travaille actuellement sur des problemes de performances assez généraux.
En effet, nous avons constaté à plusieurs reprises, que le passage en mode DOL de table APL sur lesquelles on fait des mise à jour massives, a diminué les temps de traitement pas 2, 3 voir 4.

Nous avons fait des tests sur des bcp et update massifs.
J'ai des temps et des sysmons de ces tests si ca peut aider.

Je voulais donc savoir si quelqu'un peut expliquer un tel ecart ou m'expliquer les mecanismes des mise a jour DOL et APL.
SYBASE soupçonne un nombre d'io synchrone (Page split, Last Log Page Write, OAM Page Write...) plus important dans le cas APL mais sans pouvoir l'expliquer ou le montrer.

Je sais que c'est très général mais je suis ouvert à toute idée

Merci d'avance

Jeeps64

Autre chose, quand tu passes en mode DOL, ta table est entrièrement reconstruite, et donc défragmentée. L'amélioration de perf peut aussi venir de la (à part si ta table APL était déjà défragmentée...)

Pour pouvoir mieux diagnostiquer ton problème, il nous faut plus d'infos sur tes tables (présence ou non d'un index clustered) et sur tes traitements (nombre de lignes insérées/updatées/avec curseur ou non..).

Par exemple quand tu fais un delete sur une table APL, les autres lignes situées sur la page sont immédiatement déplacées pour que toutes les lignes soient contigues. Ce processus est fait de manière asynchrone pour les tables DOL (par le housekeeper/lors d'un autre insert/lors d'un réorg).
Les updates sur les tables APL avec un index clustered soint traitées comme des delete/insert si la valeur des champs pour une des clés de l'index clustered change...


Pour plus d'infos, regarde ici:
http://infocenter.sybase.com/help/in...ses/X72250.htm
http://infocenter.sybase.com/help/to...ses/X27015.htm

Quelques indicateurs à regarder:

- les sections Index Management et Transaction Profile d'un sp_sysmon peuvent aider

- si je me souvients biens, dans asemonlogger, tu peux voir le nombre d'opération par objet (pour la table et les indexes). Il peut être utile de voir s'il y a une différence.

- tu peux aussi regarder directement dans monopenobjectactivity et MonProcessActivity l'activité pour les processus/objets concernés.

[jeeps64]

Bonjour

L'étude réalisée chez nous en ce moment est très général
On chercher surtout à mettre en place "des regles de bonne pratique" sur des mises à jour massives.

Nous avons lancé 3 tests :
- bcp in ou insert into select de 1,2 millions de lignes sur table avec 8 indexes non clustered
Resultat : 21 mins APL contre 7 mins DOL
- Updates de qq millions de lignes avec 4 indexes dont 1 clustered
Resultat : 9 mins APL contre 4 mins 40 en DOL
- Insert de 7 millions de lignes avec 4 indexes dont 1 clustered


Au niveau sysmon et Asemonlogger, nous ne constatons pas réellement de derive sur les io ni les waits.
On constate juste qu'il y a moins de "Disk Page Write" dnas le Task Management. Ce qui nous fait dire qu'en mode APL, SYBASE fait beaucoup moins d'io synchrone qu'en DOL.

Ce que tu dis (ci dessous), confirme tout a fait ce que l'on pense :

Envoyé par Roller :
Par exemple quand tu fais un delete sur une table APL, les autres lignes situées sur la page sont immédiatement déplacées pour que toutes les lignes soient contigues. Ce processus est fait de manière asynchrone pour les tables DOL (par le housekeeper/lors d'un autre insert/lors d'un réorg).
Les updates sur les tables APL avec un index clustered soint traitées comme des delete/insert si la valeur des champs pour une des clés de l'index clustered change...

Merci de tes infos
jeeps64

[Roller]

Bonjour
Ce que tu dis confirme tout a fait ce que l'on pense

Ce que j'ai dit ne concernait que les delete sur des tables APL ou des update sur des APL avec un index clustered.
Cela n'explique pas les différences plutôt étranges sur un bcpin ou un insert/select sur une table APL sans index clustered.

[jeeps64]

Bonjour

Pour cloturer le sujet, j'ai eu un retour des ingénieurs SYBASE qui nous confirme que les pages splits en APL se font de facon synchrone contrairement aux pages en mode DOL.

Ce qui explique les différences de temps en les update/insert massif en APL et en DOL.

Merci à tous de vos retours sur ce sujet

Bonne journée

jeeps64