Pb de performances suite à migration en SYBASE 15

1

Cet article résume quelques problèmes que l'on a eu lors de la migration de serveurs SYBASE 12.0 / 12.5 en 15. Tous les problèmes rencontrés ont été corrigés ou un contournement a été trouvé et mis en place.

 

Problème de lenteur sur un batch utilisant massivement des requêtes dynamiques impliquant une table temporaires.

Suite à une migration 12.5 vers 15, nous avons constaté qu'un batch utilisant massivement des requêtes dynamiques était fortement ralenti. 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 systématiquement leur plan d'exécution (5 millions sur un run)


L'optimiseur SYBASE recompile les plans des statements car il s'appuit sur les id des tables temporaires. Or, il change à chaque fois. Nous avons alors positionné le traceflag 299 qui permet de ne pas recompiler les statements à chaque exécution. A ce que j'ai compris, ce traceflag permet à l'optimiseur SYBASE d'aller chercher le plan d'un statement en cache par rapport au checksum de la requête et non plus des id des tables.

Pour info, ce traceflag comportait des bugs jusqu'en version 12.5.4. Pourquoi SYBASE ne l'a pas mis par défaut, ca, c'est une autre question !!!!

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%)

Cette analyse a pu se faire grâce à Asemonlogger nouvelle version. Dans l'onglet 'summary' / Tableau 'Summary Statistics' / Paragraphe 'Statement Cache Activity', nous avions autant de NumRecompilesSchemaChanges que de HitCount. 

 

 

Problème de contention sur la table syslogins

Nous avons constaté sur un batch qu'une contention très importante était apparue en version 15. Le batch lance des milliers voire des millions de connexions / déconnexions au serveur SYBASE. La contention se situait sur la ligne concernant le login qui lançait le batch.

Depuis la version 12.5.4, le serveur ASE écrit systématiquement les informations de comptabilité de CPU et IO dans la table syslogins de la base master. (Correction d'un problème : CR485461)

Pour désactiver l'écriture de ces compteurs, nous avons activer le traceflag 8101 (Annule la Correction citée ci-dessus).

En parallèle, nous avons désactiver la mémorisation de la dernière date de login via la commande suivante :

sp_passwordpolicy 'set', 'enable last login updates', 0 

 

Nous avons aussi augmenter les intervalles de temps que SYBASE utilise pour 'flusher' les compteurs CPU et IO lors des connexions.

sp_configure accounting
2> go
Msg 17411, Level 16, State 1:
Server 'DATASERVER', Procedure 'sp_configure', Line 322:
Configuration option is not unique.

 Parameter Name                 Default              Memory Used Config Value         Run Value            Unit                 Type
 ------------------------------ -------------------- ----------- -------------------- -------------------- -------------------- ----------
 cpu accounting flush interval          200                    0          200                  200         clock ticks          dynamic
 i/o accounting flush interval         1000                    0         1000                 1000         clock ticks          dynamic
 

 Nous les avons passer à 2147483647.

 

Problème de contention du le procedure cache

Il arrive que l'on détecte une forte charge CPU sur un serveur ASE 15 à mettre en corrélation avec une contention sur le procedure cache (Resource->rproccache_spin très élevé sur l'onglet spinlocks de Asemonlogger). Cela est du à la nouvelle gestion de l'allocation mémoire dans le procedure cache.

Un contournement proposé par SYBASE est de mettre le traceflag 753 qui permet de revenir au mode de gestion du procedure cache 12.5.

 

 

A suivre....