Discussion :

[Invité]

Salut,

J'essaie de trouver une solution pour un probleme a priori simple.

Nous avons un traitement qui effectue un begin tran et un commit. La transaction n'est pas scindable.

Le soucis c'est que le temps du commit prend un temps incommensurable par rapport au temps du traitement en lui meme.

Je cherche donc a minimiser ce temps de commit autant que possible. Une des piste que j'envisage c'est d'assigner un cache specifique dans lequel je veux binder la syslogs de ma base. Je l'ai fait et visiblement les resultats ne sont pas probants. Je chercher a savoir comment le tailler et comment faire une repartition entre 2k et 4k tout en partitionnant ce cache. Auriez-vous des pistes de tuning pour ce genre de chose ?

Je suis sur de l'ASE 12.0 (32bits) et je dispose du maximum de total memory (2 Go et des cacahuetes).

J'ai un cache specifique pour la tempdb (tres bien utilise) et mon defualt fait 1G.

Merci pour vos reponses

[mpeppler]

Ma première réaction est que le temps de commit va être principalement dépendant du système IO - puisque le commit ne peut être terminé avant que les datas soient physiquement écrits sur le disque.

Ceci étant - pour la cache on peut mettre la logio à 4k, et dans ce cas mettre en place un cache dédié avec un pool 4k qui est quasi la taille de la cache (le pool 2k n'est dans ce cas pas ou très peu utilisé).

La taille a allouer dépend évidemment aussi de la taille de la/les transactions...

Michael

[Invité]

Merci.

J'ai relance le batch en ayant apporte les modifications suivantes:

- sp_logio de 4k
- pool de 4k dans le default data cache

J'ai envisage de faire de la micro-chirurgie en allouant un cache dedie avec un ration 2k/4k de 1%/99% en bindant le cache sur la syslogs mais je suis parti sur une repartition du default data cache en 2/4 et 16.

Le traitement est toujours en cours donc j'en saurais plus dans la journee.

Par contre, qu'est-ce qui pourrait faire qu'un process "COMMIT TRANSACTION" donne l'impression de ne rien faire pendant de tres tres longues minutes/heures ? En effet, sachant que c'est au moment du commit que nous perdons le plus de temps, nous nous demandons ce qu'il fait exactement lors d'un commit. Ici le process COMMIT TRANSACTION est en sleeping quasiment tout le temps. Pourquoi ? Comment fonctionne le commit Sybase ? Que fait-il ?

Merci

[Invité]

Malgre ces modificationsm le traitement a mis plus de temps +45minutes essentiellement lie au COMMIT

Je ne comprends vraiment pas...

[mpeppler]

Qu'est ce que tu voix au niveau de l'OS lors du commit?
Est-ce que les disques sont très actifs?

Michael

[Invité]

L'OS est tres tres calme...

Voici une vue du sysmon qui tourne:

sysmon_20080613124000.txt: Group Commit Sleeps 0.0 0.0 0 0.0 %
sysmon_20080613124000.txt: Committed Xacts 0.1 n/a 32 n/a
sysmon_20080613125000.txt: Group Commit Sleeps 0.0 0.0 0 0.0 %
sysmon_20080613125000.txt: Committed Xacts 0.1 n/a 32 n/a
sysmon_20080613130000.txt: Group Commit Sleeps 0.0 0.0 0 0.0 %
sysmon_20080613130000.txt: Committed Xacts 0.1 n/a 32 n/a
sysmon_20080613131000.txt: Group Commit Sleeps 0.0 0.0 0 0.0 %
sysmon_20080613131000.txt: Committed Xacts 0.1 n/a 37 n/a
sysmon_20080613132000.txt: Group Commit Sleeps 0.0 0.0 0 0.0 %
sysmon_20080613132000.txt: Committed Xacts 0.1 n/a 32 n/a
sysmon_20080613133000.txt: Group Commit Sleeps 0.0 0.0 0 0.0 %
sysmon_20080613133000.txt: Committed Xacts 0.1 n/a 32 n/a
sysmon_20080613134001.txt: Group Commit Sleeps 0.0 0.0 0 0.0 %
sysmon_20080613134001.txt: Committed Xacts 0.1 n/a 32 n/a
sysmon_20080613135000.txt: Group Commit Sleeps 0.0 0.0 0 0.0 %
sysmon_20080613135000.txt: Committed Xacts 0.1 n/a 32 n/a
sysmon_20080613140000.txt: Group Commit Sleeps 0.0 0.0 0 0.0 %
sysmon_20080613140000.txt: Committed Xacts 0.1 n/a 32 n/a
sysmon_20080613141000.txt: Group Commit Sleeps 0.0 0.0 0 0.0 %
sysmon_20080613141000.txt: Committed Xacts 0.1 n/a 32 n/a
sysmon_20080613142001.txt: Group Commit Sleeps 0.0 0.0 0 0.0 %
sysmon_20080613142001.txt: Committed Xacts 0.1 n/a 32 n/a
sysmon_20080613143000.txt: Group Commit Sleeps 0.0 0.0 0 0.0 %
sysmon_20080613143000.txt: Committed Xacts 0.1 n/a 32 n/a


Si je comprends bien, il y a 32 transactions committed sachant que je fais des mesures toutes les 10minutes pendant 8 minutes, ca ne fait pas lourd.

Autre chose, je vais augmenter le ULC car j'ai beaucoup de context switch du au FULL ULC.

Je continue de chercher mais je prends toutes vos bonne idees

[Roller]

Il nous faudrait la log complète du sp_sysmon.
Peux-tu faire tourner un sp_sysmon pendant le traitement et poster la log en pièce jointe?

[mpeppler]

Et il faudrait en même temps monitorer les ressources OS (en particulier disques)

Michael

[Invité]

J'ai des sysmon qui tournent toute la journee: lances toutes les 10minutes pendant 8 minutes.

Au moment du commit, tous les compteurs sont a 0 ou presque. Dans le context switch, le cache miss est a 99% et seuls les devices de logs font des I/Os.

Cote OS, on voit seulement des acces en lecture/ecriture sur ses devices pendant toute la duree du commit... La CPU est OK (30%), la memoire aussi.

Il faut vraiment que je comprenne ce qui peut bien se passe pendant un COMMIT TRANSACTION (le process est tres tres souvent en "sleeping").

[mpeppler]

Est-ce que tu peux poster un sp_sysmon complet qui illustre le problème?

Merci,

Michael

[Invité]

Voila je suis dans la fameuse phase du commit sur mon traitement:

1> dbcc stacktrace(1)
2> go
pc: 0x0026da34 upsleepgeneric+0x254()
pc: 0x00274bdc bufread+0x160()
pc: 0x002bbad0 getpage_with_validation+0x344()
pc: 0x002d2238 apl_getnext+0x3a8()
pc: 0x00332188 xsc__syslogs_getnext+0x3c()
pc: 0x003323b8 xls_getnext+0x54()
pc: 0x0036d63c pg_commitdealloc+0xcc()
pc: 0x002eb414 xact__endxact+0x160()
pc: 0x002d9714 xact__commitxact+0x140()
pc: 0x002d93a0 xact__commit_local+0x4c()
pc: 0x002d92a8 xact_commit+0x18()
pc: 0x0029b018 s_execute+0x4bc8()
[Handler pc: 0x003d7d78 s_handle installed by the following function:-]pc:
0x002ee1a0 sequencer+0x6b4()
pc: 0x002efbe0 execproc+0x3c0()
pc: 0x00297b1c s_execute+0x16cc()
[Handler pc: 0x003d7d78 s_handle installed by the following function:-]pc:
0x002edd00 sequencer+0x214()
pc: 0x001f950c tdsrecv_language+0xa8()
[Handler pc: 0x0041b324 hdl_backout installed by the following
function:-][Handler pc: 0x005817e0 ut_handle installed by the following
function:-][Handler pc: 0x005817e0 ut_handle installed by the following
function:-]pc: 0x0025a570 conn_hdlr+0x8d4()
pc: 0x00259a6c conn_hdlr+0x8()
DBCC execution completed. If DBCC printed error messages, contact a user with
System Administrator (SA) role.


Un sp_who revele que le process COMMIT TRANSACTION est sleeping. Cote OS, les devices de logs (sur un disque separe) sont accedes a fond les ballons (mais aucun I/O wait).

Que fait Sybase durant un COMMIT ???????

[mpeppler]

T'énérve pas...

Combien de lignes ont été mises à jour?

Durant le commit les buffer modifiés sont écrits dans la syslog (à ma connaissance).

Un sysmon complet devrait donner plus d'info sur ce qui ce passe.

Michael

[Invité]

Est-ce que tu peux poster un sp_sysmon complet qui illustre le problème?

Merci,

Michael

Petit sysmon correspondant a ma phase de commit (toujours en cours)

[Invité]

T'énérve pas...

Combien de lignes ont été mises à jour?

Durant le commit les buffer modifiés sont écrits dans la syslog (à ma connaissance).

Un sysmon complet devrait donner plus d'info sur ce qui ce passe.

Michael

Je ne m'enerve pas contre toi

Pour repondre a ta question, il y a environ 6 millions de mouvements dans la base.

Un truc qui me chagrine fort c'est le "checks for returning I/O" qui est en permanence dans les 98% .

Je n'ai pas de sysmon complet, il faut que je le relance pour ca.

Est-ce que le fait d'avoir des APL defered peut impacter la duree du commit "final" ?

[mpeppler]

6 millions de modifs committées en une seule fois?

Dans ce cas le comportement ne me surprend pas - la seule chose à faire est d'optimiser le sous-système IO. Voir par example la réponse de Bret Halford sur un sujet similaire:

http://groups.google.com/group/sybas...5d758f88d7cefa

Une chose hyper importante dans cette situation: est-ce que tes IOs sont biens asyncrones?
(par example, sous HP-UX on ne peux PAS faire d'IO async. avec des devices sur des fichiers OS)

Michael

[Roller]

Il y a beaucoup de lectures physiques sur ton device de log.
Et il y a de la rotation dans ton pool de 4K. Je pense que ton cache est sous-dimensionné.
Pour éviter que toutes les écritures aient lieu lors du commit, tu peux aussi tester d'augmenter la 'wash size' de ce cache. Mais je ne sais pas si c'est bon quant il y a beaucoup de deferred updates, à voir.
Si tu nous donnais le sql du traitement et le plan d'exécution, on pourrait essayer d'éviter le deferred update (ce n'est pas toujours possible).

Quelle est l'occupation maximale de ton espace de log pendant le traitement??
Ca pourrait t'aider à dimensionner ton pool.
Quelle est la taille du pool de 4K? La wash size de ce pool?

[Invité]

6 millions de modifs committées en une seule fois?

Dans ce cas le comportement ne me surprend pas - la seule chose à faire est d'optimiser le sous-système IO. Voir par example la réponse de Bret Halford sur un sujet similaire:

http://groups.google.com/group/sybas...5d758f88d7cefa

Une chose hyper importante dans cette situation: est-ce que tes IOs sont biens asyncrones?
(par example, sous HP-UX on ne peux PAS faire d'IO async. avec des devices sur des fichiers OS)

Michael

Merci pour le lien. Je viens de me faire confirmer par l'equipe des devs que le traitement ne faisait qu'une seule et unique transaction. C'est le cas.

Je suis en RAW device (sauf pour tempdb) et bien en I/O async meme si je n'ai pas l'impression que cela depote cote APF...

Autre point, les tables impactees sont surtout en APL et je comptabilise pres de 40 000 page splits.

[Invité]

Il y a beaucoup de lectures physiques sur ton device de log.
Et il y a de la rotation dans ton pool de 4K. Je pense que ton cache est sous-dimensionné.
Pour éviter que toutes les écritures aient lieu lors du commit, tu peux aussi tester d'augmenter la 'wash size' de ce cache. Mais je ne sais pas si c'est bon quant il y a beaucoup de deferred updates, à voir.
Si tu nous donnais le sql du traitement et le plan d'exécution, on pourrait essayer d'éviter le deferred update (ce n'est pas toujours possible).

Quelle est l'occupation maximale de ton espace de log pendant le traitement??
Ca pourrait t'aider à dimensionner ton pool.
Quelle est la taille du pool de 4K? La wash size de ce pool?

Oui il y a un peu de turnover au niveau du 4k mais uniquement lors du COMMIT TRAN le reste du temps, c'est tres bas au niveau du turnover. Donc le 4k est probablement sous-dimensionne pour la phase commit mais pas pour le reste du temps. Concernant le fait de l'augmenter, cela va a l'encontre de ce que j'ai lu dans le fil donne par mpeppler sur google.

Sinon, pour information, sur 1500M de default data cache, 700 sont alloues au pool de 4k et sa wash est a 61M.

Je ne peux malheureusement pas donne le showplan ni les ordres SQL (c'est une procedure qui envoie pas moins d'une cinquantaine d'autres procs imbriquees). Les deferred sont inevitables a mon avis.

Merci pour tout le temps passe a m'aider vu la qualite du support Sybase...

[Roller]

Effectivement 700Mo c'est assez large.
Je te conseille d'augmenter la wash size, ce qui aura un effet quasi-équivalent à la diminution de la taille du cache au niveau des écritures.

[Invité]

Effectivement 700Mo c'est assez large.
Je te conseille d'augmenter la wash size, ce qui aura un effet quasi-équivalent à la diminution de la taille du cache au niveau des écritures.

De combien faudrait-il l'augmenter ? Une proportion de 50/50 ?

Sinon, merci pour l'idee :-)