Bonjour à tous,
avez-vous déjà rencontré des mauvais temps de réponse au niveau du GUI lors d'interrogations type why, log, statistics, sysout ..... ?
Ceci se manifeste particulièrement quand le process Control-M 'p_ctmco' est fort actif (exemple: soumission simultanée de 20 jobs)
Control-M/Server 6.1.03
Control-M/EM 6.1.03
Oracle 9.2 (dedi?e)
Solaris 9
Cordialement
Walty
Mauvais temps de r?ponse via le GUI
Oui, il est possible que vous ayez un problème de temps de r?ponse.
Si vous avez plusieurs GATEWAY définies sur votre ECS, vous pouvez constater que votre soucis d'accés aux SYSOUT et à WHY ne concerne qu'une seule d'entre elles.
Dans tous les cas le simple fait d'arrêter et relancer la Gateway premet la création ou la mise à jour selon le cas des OLD NET et de résoudre cette lenteur.
Dans le cas ou le problème est plus général sur l'ensemble de vos GATEWAY il est porblable que votre soucis soit au niveau des Logs de votre base de donn?es qui sont généralement chargées.
C'est principalement vrai sous SYBASE, je n'en suis tout à fait certain en ce qui concerne ORACLE.
L'arrêt / relance de votre database résoudra votre soucis.
F. YOT
Si vous avez plusieurs GATEWAY définies sur votre ECS, vous pouvez constater que votre soucis d'accés aux SYSOUT et à WHY ne concerne qu'une seule d'entre elles.
Dans tous les cas le simple fait d'arrêter et relancer la Gateway premet la création ou la mise à jour selon le cas des OLD NET et de résoudre cette lenteur.
Dans le cas ou le problème est plus général sur l'ensemble de vos GATEWAY il est porblable que votre soucis soit au niveau des Logs de votre base de donn?es qui sont généralement chargées.
C'est principalement vrai sous SYBASE, je n'en suis tout à fait certain en ce qui concerne ORACLE.
L'arrêt / relance de votre database résoudra votre soucis.
F. YOT
Last edited by fyot on 04 Dec 2006 11:57, edited 2 times in total.
Mauvais temps de réponse via le GUI
Merci de votre réponse.
Ce phénomène se reproduit au niveau de toutes nos GATEWAY.
Sachant que chaque environnement (serveur) est individuel, utilise 1 seule GATEWAY et ne communiquent pas entre eux.
Chaque serveur est utilisé uniquement pour le scheduling et possède sa propre base Oracle ainsi que les composants Control-M/Server et Control-M Enterprise Manager.
L'utilisation de multiples CS process (max 6 , min 4) a été mise en place coté Control-M/Serveur.
Le fait d'effectuer un STOP/START des composants ou de la DB ne semble pas résoudre ce temps de latence.
Un call chez BMC est actuellement ouvert pour investigations.
Cordialement
Walty
Ce phénomène se reproduit au niveau de toutes nos GATEWAY.
Sachant que chaque environnement (serveur) est individuel, utilise 1 seule GATEWAY et ne communiquent pas entre eux.
Chaque serveur est utilisé uniquement pour le scheduling et possède sa propre base Oracle ainsi que les composants Control-M/Server et Control-M Enterprise Manager.
L'utilisation de multiples CS process (max 6 , min 4) a été mise en place coté Control-M/Serveur.
Le fait d'effectuer un STOP/START des composants ou de la DB ne semble pas résoudre ce temps de latence.
Un call chez BMC est actuellement ouvert pour investigations.
Cordialement
Walty
Bonjour,
Désolé de ne pouvoir plus vous aider, néanmoins l'installation des bases de donn?es SYBASE et ORACLE sont faite selon une procédure standard.
Vous trouverez sur ce site quelques idées pour améliorer les performances d'une base SYBASE. Dans le cas d'Oracle n'hésitez pas à faire appel à un bon DBA qui vous préconisera des solutions d'optimisation.
D'autre part si vous utilisez Control-M sur une plateforme de type Unix il faut savoir que l'application va créer beaucoup d'I/O surtout dans ./ctm/tmp et ./ctm/pid.
Vous pouvez créer un lien symbolique vers un Filesystem en Swap memory qui augmentera ses performances (Voir sur le site aussi), solution qui peut aussi être mise en place sous Windows avec un lecteur RAMDISK.
F.YOT
Désolé de ne pouvoir plus vous aider, néanmoins l'installation des bases de donn?es SYBASE et ORACLE sont faite selon une procédure standard.
Vous trouverez sur ce site quelques idées pour améliorer les performances d'une base SYBASE. Dans le cas d'Oracle n'hésitez pas à faire appel à un bon DBA qui vous préconisera des solutions d'optimisation.
D'autre part si vous utilisez Control-M sur une plateforme de type Unix il faut savoir que l'application va créer beaucoup d'I/O surtout dans ./ctm/tmp et ./ctm/pid.
Vous pouvez créer un lien symbolique vers un Filesystem en Swap memory qui augmentera ses performances (Voir sur le site aussi), solution qui peut aussi être mise en place sous Windows avec un lecteur RAMDISK.
F.YOT
Last edited by fyot on 04 Dec 2006 11:55, edited 1 time in total.
Mauvais temps de réponse via le GUI
Problème identifié, bottleneck situé au niveau des disks impactant la DB Oracle install?e en local.
Celle-ci a été déportée sur un SAN, l'utilisation d'un filesystem en swap memory a aussi été mis en place pour ./ctm/tmp et ./ctm/pid
Les résultats au GUI donnent pleinement satisfaction.
Cordialement
Walty
Celle-ci a été déportée sur un SAN, l'utilisation d'un filesystem en swap memory a aussi été mis en place pour ./ctm/tmp et ./ctm/pid
Les résultats au GUI donnent pleinement satisfaction.
Cordialement
Walty