De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft hoe langzaam Unified Contact Center Express (UCCX) activiteiten, die lokale UCCX-databases vereisen, kunnen worden uitgevoerd. De AppAdmin-pagina's worden langzaam geladen, updates aan AppAdmin duren lang om effect te sorteren, een vertraging in de reactie op een mapvraag, Workforce Manager kan UCCX-gegevens niet-gegevens vragen en andere problemen met prestaties en stabiliteit.
De opdracht toont proceslading die in de CLI is ingevoerd, en toont aan dat de CUXINIT een grote hoeveelheid CPU verbruikt. Het uccxoninit-proces vertegenwoordigt de UCCX Informix-gegevensinstantie die op de UCCX-server draait.
Bijgedragen door Sridhar Chandrasekharan, Ryan LaFountain en Ben Wollak, Cisco TAC-engineers.
De database engine die de UCCX-toepassing ondersteunt, is de Informix van IBM. Configuratie- en historische informatie die aan de AppAdmin-pagina van UCCX wordt toegevoegd en door de UCCX-toepassing wordt geproduceerd, wordt opgeslagen in de UCCXInformix-instantie.
De UCCX-toepassing biedt drie gebruikers die kunnen worden gebruikt om direct toegang te krijgen tot de UCCX-database om informatie te extraheren voor wallbordtoepassingen, Quality Management, Workforce Management en aangepaste historische rapportage.
De gebruikersinformatie, de permissies van elke gebruiker en het beoogde doel van elke gebruiker worden hier beschreven:
behangsel - Deze gebruiker heeft alleen recht op de tabellen in de real-time database die momentopnamen bevatten van realtime statistieken die zijn geschreven uit het geheugen van UCCX Engine. De selectiecompensiteiten die beperkt zijn tot tabellen RTCSQsSummary en RTICDS betekenen dat de uccxwallboard-gebruiker gebruikt moet worden om de UCCX-database regelmatig te vragen met eenvoudige, niet-complexe vragen die bedoeld zijn om uit een maptoepassing te komen.
In UCCX release 10.0 en hoger voert u de DBF-opdracht <totaaluren> <interval> uit om met het herstellen van de prestaties te beginnen in de UCCX-database. Het interval argument in deze opdracht bepaalt de frequentie van de spoorverzameling en het totale uur argument bepaalt de totale hoeveelheid tijd die de overtrekbeurt loopt voordat het wordt uitgeschakeld. Deze parameters zijn optioneel. Als deze niet worden opgegeven wanneer de opdracht wordt uitgevoerd, worden de standaardwaarden van 20 minuten en 10 uur gebruikt.
Voer bijvoorbeeld de utils uccx database dbperf start 24 30 opdracht in om prestatietracering op de database mogelijk te maken en verzamel om de 30 minuten gegevens over prestatiestatistieken voor 24 uur.
Instructies voor het verzamelen van de gegevens die de CLI-opdracht heeft verkregen, worden in de opdrachtoutput afgedrukt.
Nadat de totale uren is gegeven, wordt de gegevensverzameling automatisch stopgezet. Om de gegevensverzameling handmatig te stoppen, voert u de opdracht utils uccx-database dbperf stop in.
Als de UCCX-versie release 9.0(2) of eerder is en de utils uccx-database dbperf Aangezien deze opdracht niet beschikbaar is, neemt u contact op met het TAC (Technical Assistance Center) voor verdere assistentie.
TAC voert het DBP.sh-script dat aan Cisco bug ID is toegevoegd handmatig uit CSCuc68413 met toegang tot de externe ondersteuningsaccount.
Wanneer u bepaalt wanneer u de uitvoering van het script handmatig of via de CLI-opdracht wilt starten, de periodiciteit en de totale tijd, dient u ervoor te zorgen dat de CPU die door de ucxoninit het proces tijdens die perioden sterk fluctueert of hoog blijft om de nodige informatie te verzamelen voor de analyse van de basisoorzaak .
Daarnaast voert u periodiek de opdracht voor het verwerken van beelden in om te bepalen wanneer de CPU fluctueert, zodat de logbestanden die zijn verzameld door het dbperf-overtrekscript gecorreleerd worden.
De door de uitvoering van onstat -g ses 0 verzamelde logboeken van het dbperf script tonen actieve vragen die tegen de UCCX database zijn afgegeven. Hoge CPU's in het ucxonit-proces zijn doorgaans het resultaat van complexe vragen die lang duren om uit te voeren. Het doel is om de vragen te bepalen die de meeste middelen verbruiken, de bronclient voor die vragen te bepalen, de vragen van de client voor onmiddellijke oplossing uit te schakelen en de lange lopende vragen voor permanente oplossing te optimaliseren.
In de logbestanden die door het dbperf-script zijn vergaard, zoekt u naar vragen die waarschijnlijk hoge fluctuaties in CPU’s of een duurzaam hoog CPU-verbruik bij het ucxoninit-proces veroorzaken.
Verdachte vragen:
Een voorbeeld met een complex query dat een HR tabel run zoals CUBE wordt weergegeven:
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
Het bovenstaande voorbeeld toont een ingewikkelde vraag, die door een frauderende gebruiker is ingevoerd en afkomstig is van de WBBOX van de gastheer die een invloed op de UCCX-database kan hebben als deze vaak werd ingevoerd of periodiek werd ingevoerd voordat de vorige query resultaten had teruggegeven.
Hoewel zeldzaam, kunnen UCCX-databases ook worden gedegradeerd (en kan het CPU-gebruik van de ucxoninit het proces fluctueert of blijft hoog) als gevolg van het ingebouwde zuiveringsproces. Het zuiveringsproces is ontworpen om gegevens uit de configuratie en historische tabellen in de UCCX-database te verwijderen om de grootte van de database te behouden. De zuivering kan worden gepland op basis van de grootte van de database of het oudste record in de database.
Wanneer het zuiveringsproces wordt uitgevoerd, worden de gegevens met één query verwijderd. Dit gebeurt niet op basis van de hoeveelheid gegevens die moet worden verwijderd. Dit betekent dat als de purge een grote hoeveelheid gegevens detecteert die moet worden verwijderd, er één query wordt gegeven in een poging om deze gegevens te verwijderen.
De wijziging van het zuiveringsschema of de parameters van de UCCX AppAdmin-pagina om de purge te plannen voor het verwijderen van een grote hoeveelheid gegevens kan ertoe leiden dat deze enkele query bij de volgende geplande purge een aanzienlijke hoeveelheid tijd nodig heeft om te voltooien. Daarom wordt het CPU-gebruik van de gegevensinstantie erdoor bevorderd.
In de output van het dbperf script kan de purge query worden gezien. Het moet de enige query zijn die is ingevoerd door gebruiker uccxuser die de sp_purge opslagprocedure aanroept.
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))));
Gebaseerd op recente ervaring van Cisco TAC en Cisco Development Engineering, zijn dit de meest voorkomende problemen die een hoog CPU-gebruik bij het productieproces veroorzaken: