Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit comment les activités Unified Contact Center Express (UCCX), qui nécessitent un accès local à la base de données UCCX, peuvent se dérouler lentement. Cela entraîne un chargement lent des pages AppAdmin, des mises à jour de AppAdmin prenant beaucoup de temps pour prendre effet, un retard dans la réponse à une requête de fond d'écran, Workforce Manager ne peut pas interroger les données UCCX, et d'autres problèmes de performances et de stabilité.
La commande show process load, entrée dans la CLI, montre que uccxoninit consomme une grande quantité de CPU. Le processus uccxoninit représente l'instance de base de données UCCX Informix qui s'exécute sur le serveur UCCX.
Contribué par Sridhar Chandrasekharan, Ryan LaFountain et Ben Wollak, ingénieurs du centre d'assistance technique de Cisco.
Le moteur de base de données qui prend en charge l'application UCCX est Informix d'IBM. Les informations de configuration et d'historique ajoutées à la page AppAdmin d'UCCX et produites par l'application UCCX sont stockées dans l'instance UCCX Informix.
L'application UCCX fournit trois utilisateurs qui peuvent être utilisés pour accéder à la base de données UCCX directement afin d'extraire des informations à des fins d'applications de fond d'écran, de gestion de la qualité, de gestion de la main-d'oeuvre et de rapports historiques personnalisés.
Les informations sur l'utilisateur, les autorisations de chaque utilisateur et la fonction prévue de chaque utilisateur sont décrites ici :
uccxwallboard - Cet utilisateur dispose d'autorisations de sélection uniquement sur les tables de base de données en temps réel qui contiennent des instantanés de statistiques en temps réel écrites à partir de la mémoire du moteur UCCX. Les autorisations de sélection restreintes aux tables RTCSQsSummary et RTICDStatistics signifient que l'utilisateur uccxwallboard doit être utilisé pour interroger UCCX fréquemmentavec des requêtes simples et non complexes destinées à être obtenues par une application wallboard.
Dans UCCX version 10.0 et ultérieure, entrez la commande utils uccx database dbperf start <totalHours> <interval> afin de commencer le suivi des performances sur la base de données UCCX. L'argument interval de cette commande détermine la périodicité de la collection de traces et l'argument totalHours détermine la durée totale d'exécution du suivi avant sa désactivation. Ces paramètres sont facultatifs. Si elles ne sont pas spécifiées lors de l'exécution de la commande, les valeurs par défaut de 20 minutes et 10 heures sont utilisées.
Par exemple, entrez la commande utils uccx database dbperf start 24 30 afin d'activer le suivi des performances sur la base de données et de collecter des données sur les statistiques de performance toutes les 30 minutes pendant 24 heures.
Les instructions de collecte des données obtenues par la commande CLI sont imprimées dans le résultat de la commande.
Après le totalHeures donné, la collecte de données s'arrête automatiquement. Afin d'arrêter manuellement la collecte de données, entrez la commande utils uccx database dbperf stop.
Si la version UCCX est la version 9.0(2) ou antérieure et utils uccx base de données dbperf n'est pas disponible, contactez le Centre d'assistance technique (TAC) pour obtenir de l'aide.
TAC exécutera le script dbperf.sh associé à l'ID de bogue Cisco CSCuc68413 manuellement avec l'accès au compte d'assistance à distance.
Lorsque vous déterminez quand démarrer l'exécution du script manuellement ou via la commande CLI, la périodicité et le temps total, assurez-vous que le CPU consommé par le uccxoninit le processus fluctue considérablement ou reste élevé au cours de ces périodes afin de recueillir les informations nécessaires à l'analyse des causes premières.
En outre, entrez périodiquement la commande show process load pour déterminer quand le CPU fluctue afin de corréler les journaux collectés par le script de traçage dbperf.
Les journaux collectés par le script dbperf lors de l'exécution d'onstat -g ses 0 montrent les requêtes actives émises sur la base de données UCCX. Le CPU élevé sur le processus uccxoninit est généralement le résultat de requêtes complexes qui prennent beaucoup de temps à s'exécuter. L'objectif est de déterminer les requêtes qui consomment le plus de ressources, de déterminer le client source pour ces requêtes, de désactiver les requêtes du client pour une résolution immédiate et d'optimiser les requêtes de résolution permanente en cours d'exécution.
Dans les journaux collectés par le script dbperf, recherchez les requêtes qui provoquent le plus probablement de fortes fluctuations du CPU ou une consommation élevée de CPU soutenue par le processus uccxoninit.
Requêtes suspectes :
Un exemple avec une requête complexe qui implique une exécution d'une table HR sous la forme uccxhruser est présenté ici :
session #RSAM total used dynamic
id user tty pid hostname threads memory memory explain
435050 uccxhrus WBBOX 836 10.16.5. 1 90112 80712 off
...................
Current SQL statement :
SELECT x.resourceName, t.eventType, x.datetime, x.extension FROM ( SELECT
t1.resourceID, t1.resourceName, t1.extension, MAX(t2.eventDateTime) AS
datetime FROM Resource AS t1, AgentStateDetail AS t2 WHERE t2.agentID
= t1.resourceID AND t1.assignedTeamID = 21 and t1.active GROUP BY
t1.resourceID, t1.resourceName, t1.extension ) AS x, AgentStateDetail AS
t WHERE t.agentID = x.resourceID AND t.eventDateTime = x.datetime
ORDER BY x.resourceName
L'exemple ci-dessus montre une requête complexe, entrée par uccxhruser provenant de l'hôte WBBOX qui pourrait avoir un impact sur les performances de la base de données UCCX si elle a été saisie souvent ou régulièrement avant que la requête précédente n'ait renvoyé les résultats.
Bien que rare, les performances de la base de données UCCX peuvent également se dégrader (et l'utilisation du CPU du uccxoninit fluctue ou reste élevé), en raison du processus de purge intégré. Le processus de purge est conçu pour supprimer des données des tables de configuration et d'historique de la base de données UCCX afin de maintenir la taille de la base de données. La purge peut être planifiée en fonction de la taille de la base de données ou du plus ancien enregistrement contenu dans la base de données.
Lorsque le processus de purge s'exécute, les données sont supprimées avec une requête. Il n'est pas effectué itérativement en fonction de la quantité d'enregistrements à supprimer. Cela signifie que si la purge détecte une grande quantité de données qui doit être supprimée, elle émet une requête unique pour tenter de supprimer ces données.
La modification de la planification ou des paramètres de purge de la page UCCX AppAdmin afin de planifier la purge pour supprimer une grande quantité de données peut entraîner la fin de cette requête unique, lors de la purge planifiée suivante, pour un temps important. Par conséquent, il augmente l'utilisation du CPU de l'instance de base de données.
Dans la sortie du script dbperf, la requête de purge peut être vue. Il doit s'agir de la seule requête entrée par l'utilisateur uccxuser qui appelle la procédure stockée sp_purge.
session #RSAM total used dynamic
id user tty pid hostname threads memory memory explain
5628 uccxuser - -1 CC-EXPR- 1 544768 523408 off
Current SQL statement in procedure db_cra:sp_purge
proc-counter 0x0x4ccf9260 opcode SQL
delete from contactroutingdetail
where (exists
(select 1
from contactcalldetail as ccdr
where (and (and (and (and (and (= contactroutingdetail.sessionid,
ccdr.sessionid), (= contactroutingdetail.nodeid, ccdr.nodeid)),
(= contactroutingdetail.sessionseqnum, ccdr.sessionseqnum)),
(= contactroutingdetail.profileid, ccdr.profileid)), (>= ccdr.enddatetime,
p_purgefrom)), (< ccdr.enddatetime, p_purgeto))));
Sur la base de l'expérience récente du centre d'assistance technique de Cisco et de l'ingénierie de développement de Cisco, voici les problèmes les plus courants qui provoquent une utilisation élevée du CPU sur le processus uccxoninit :