Discussion :

[jeeps64]

Bonjour

Nous avons migré une application (PROGICIEL) de la version 12.5.3 à 15.0.3
Nous avons constaté une détérioration très importante des performances
Le positionnement de l'option 'compatibility mode' à 1 nous a permis de retrouver des temps acceptables (mais toujours moins bon qu'en 12.5)

Nous travaillons actuellement sur la suppression de cette option afin de travailler en ASE 15 Optimiseur 15 (compatibility mode à 0). Car elle est fortement buggée.

Cette application utilise massivement des curseurs. Nous ne pouvons modifier le code de celle-ci.

Est-ce que quelqu'un a rencontré des problèmes de performances de curseurs sur la version 15 de SYBASE ?
Pour info, nous avons une charge CPU très importante pour une consommation io assez faible. Je n'arrive pas à identifier d'ou peut provenir cette charge CPU

Merci de toutes infos sur ce genre de sujet

jeeps64

[thx5959]

Bonjour
Je vous conseille de passer en ESD #3
Gros bugs corrigés .
Comme pb de perf sur des requetes utilisant certain type de jointure
Cdlt

[jeeps64]

L'ESD 2 vient de sortir (mois d'aout je crois)
Les tests effectué avec celui-ci ne sont pour l'instant pas concluant

Pour info, nous avons identifié un gros bug sur les requêtes utilisant un select distinct vers une table #.
En effet,
en laissant le select into, la requête prend un plan pourri et fait des millions d'io
en supprimant le into #table, la requête fait 10 io et prend le bon plan
Le contournement est de désactiver l'option opportunistic_distinct_view à off.
La correction se fera dans l'ESD3 (février 2010 dixit SYBASE) ou ESD 4

Maintenant, on a l'impression que les plans sont bons mais qu'il y a une charge CPU excessive par rapport à l'activité io. On soupconne une dérive lors de l'utilisation massive de curseur.

Quand je dis massive , c'est 300000 ouvertures / fetch / desallocate de curseur par heure

jeeps64

[mpeppler]

J'ai vu dans les forums sybase (forums.sybase.com) que d'autres utilisateurs ont eu le même problème, à priori.

Je n'ai pas tout lu (manque de temps, et nous on préfère ne pas utiliser de curseur... :-) ) mais le gros usage CPU fait penser que l'optimiseur bosse plus que nécessaire.

Est-ce que les indexes ont un très grand nombre de histogram steps dans les statistiques?

Michael

[jeeps64]

Ça dépend des tables mais il peut arriver sur certaines tables à 500

Penses-tu à quelque chose de particulier au sujet des histogrammes ?

jeeps64

[mpeppler]

L'optimizeur en 15 doit plus travailler - si il y a beaucoup de step cela prend plus de temps pour trouver la bonne solution.

Le thread sur groups.google.com:

http://groups.google.com/group/sybas...5fc5d0a89e235#

Michael

[jeeps64]

Bonjour

Nous avons finalement trouvé la cause de notre surcharge CPU lor de la migration 12.5 vers 15.
En effet, l'application fait des milliers voire des millions de requête / curseur avec une jointure sur une table temporaire (table en #)
Les requêtes étant quasiment les mêmes, nous avons identifié qu'elles recompilaient tout le temps leur plan d'exécution (5 millions sur un run)

Nous avons alors positionner le traceflag 299 qui permet de ne pas recompiler les statements à chaque exécution.
Pour info, ce traceflag comportait des bugs jusqu'en version 12.5.4. Pourquoi SYBASE ne l'a pas mis par défaut ????

Nous avons eu un gain énorme en terme de CPU ainsi que les temps d'exécution du batch complet (Avant durée 2h et CPU 80%, Apres 1h et CPU 40%)

jeeps64

[mpeppler]

Nous avons essayé le -T299 sous 15.0.3 ESD 2, mais cela nous a généré des stack-traces assez conséquent... on attend une réponse de Sybase TS a ce sujet!

Michael

[jeeps64]

Merci de l'info
On est justement entrain de voir a mettre en palce l'ESD 2
Pas cool ; ))

merci encore

jeeps64

[jeeps64]

Mickael,

Je serai intéressé de savoir quel type d'action a entrainé la stacktrace et le retour du support a ce sujet (le CR si tu as)
Je vais chercher de mon coté

Merci encore
jeeps64

[mpeppler]

On a fait pas mal de tests ces derniers jours sur le comportement du -T299 en 15.0.3 ESD 2.

En fait - le problème semble venir de procs imbirquées qui utilisent massivements les tables tempo, et qui ont été soumises en 12.5.x et ensuite upgradées en 15.x.

Si une proc génère un stack trace avec le -T299 il suffit de la resoumettre (cad de la recréer) pour résoudre le problème.

De plus le bug que nous avons mis à jour a de bonnes chances d'être fixé en 15.0.3 ESD 3.

Michael

[jeeps64]

Y a-t-il un cas ouvert chez SYBASE à ce sujet ?
Je voudrais les solliciter

jeeps64