Monitoring en probleemoplossing bij hoge CPU’s van Cisco Unified Communications Manager 6.0, met Real Time Monitoring Tool (RTMT)

Inleiding

Dit document biedt stappen om te helpen bij controle en probleemoplossing bij problemen die verband houden met een hoog processorgebruik op Cisco Unified Communications Manager 6.0 met RTMT.

Voorwaarden

Vereisten

Cisco raadt u aan bekend te zijn met dit onderwerp:

• Cisco Unified Communications Manager

Gebruikte componenten

De informatie in dit document is gebaseerd op deze agendapunten:

• Systeemtijd, Gebruikerstijd, IOWait, Soft IRQ en IRQ

• Waarschuwingen voor CPU-koppeling

• Identificatie van proces dat de meeste CPU gebruikt

• Hoge IOWait

• Hoog IOWitten gevolge van gemeenschappelijke verdeling

• Identificatie van proces verantwoordelijk voor schijf-I/O

• Code geel

• Code geel maar totaal CPU gebruik is slechts 25% - waarom?

De informatie in dit document is gebaseerd op Cisco Unified Communications Manager 6.0.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Systeemtijd, Gebruikerstijd, IOWait, Soft IRQ en IRQ

Het gebruik van RTMT om potentiële problemen met CPU te isoleren kan een zeer nuttige stap van het oplossen van problemen zijn.

Deze termen vertegenwoordigen het gebruik van RTMT CPU- en geheugenpaginarapporten:

• %systeem: het percentage van het CPU-gebruik dat zich voordeed bij de uitvoering op systeemniveau (kernel)

• %Gebruiker: het percentage van het CPU-gebruik dat in de uitvoering op gebruikersniveau is opgetreden (toepassing)

• %IOWait: het percentage van de tijd dat de CPU niet actief was, omdat werd gewacht op een opmerkelijk schijf-I/O-verzoek

• %SoftIRQ: het percentage van de tijd dat de processor uitgestelde IRQ-verwerking uitvoert (bijvoorbeeld verwerking van netwerkpakketten)

• %IRQ het percentage van de tijd dat de processor het interrupt request uitvoert, dat aan apparaten wordt toegewezen voor onderbreking, of een signaal naar de computer verstuurt wanneer de verwerking is voltooid

Waarschuwingen voor CPU-koppeling

CPUPegging/CallProcessNodeCPUPegging waarschuwt het gebruik van de CPU op basis van de ingestelde drempels:

Opmerking: %CPU is berekend als %systeem + %gebruiker + %nice + %wachttijd + %softirq + %irq

Waarschuwingsberichten omvatten deze:

• %system, %user, %nice, %iowait, %softirq en %irq

• Het proces dat de meeste CPU’s gebruikt

• De processen die op Uninterruptible schijfslaap wachten

Waarschuwingen voor CPU-koppeling kunnen in RTMT worden gegenereerd vanwege een hoger CPU-gebruik dan het watermerkniveau. Aangezien CDR een intensieve toepassing is voor CPU’s wanneer deze wordt geladen, controleert u of u de waarschuwingen ontvangt in dezelfde periode als waarin de CDR is geconfigureerd om rapporten uit te voeren. In dit geval kunt u de drempelwaarden voor RTMT verhogen. Raadpleeg Waarschuwingen voor meer informatie over RTMT-waarschuwingen.

Identificatie van proces dat de meeste CPU gebruikt

Als %system en/of %user hoog genoeg is om een waarschuwing voor koppeling te genereren, controleert u het waarschuwingsbericht om te zien welke processen de meeste CPU’s gebruiken.

Opmerking: Ga naar de pagina RTMT-proces en sorteer op %CPU om de hoge CPU-processen te identificeren.

Opmerking: voor de postmortemanalyse volgt de RIS Troubleshooting PerfMon Log het proces %CPU-gebruik en volgt het op systeemniveau.

Hoge IOWait

Hoog %IOWait wijst op I/O-activiteiten met hoge schijven. Overweeg het volgende:

• IOWait is te wijten aan intensieve geheugenuitwisseling.

  Controleer de %CPU-tijd voor wisselpartitie om te zien of er veel activiteit is in het geheugen. Aangezien Muster ten minste 2G RAM heeft, is het waarschijnlijk dat een geheugenlek een grote geheugenuitwisseling veroorzaakt.

• IOWait is toe te schrijven aan DB-activiteit.

  DB is in de eerste plaats de enige die toegang heeft tot Active Partition. Als %CPU tijd voor actieve partitie hoog is, is er waarschijnlijk veel DB-activiteit.

Hoge IOWit vanwege gemeenschappelijke partitie

Common (of Log) Partition is de locatie waar overtrek- en logbestanden worden opgeslagen.

Opmerking: Controleer deze:

• Trace & Log Central—Is er een traceeractiviteit? Als de vraagverwerking wordt beïnvloed (namelijk CodeYellow), pas het programma van de spoorinzameling aan. Als ook de zip optie wordt gebruikt, schakelt u deze uit.

• Overtrekken instellen—Op het Gedetailleerde niveau genereert CallManager nogal een beetje overtrekken. Als hoog %IOWait en/of CCM zich in de status CodeYellow bevindt en de instelling voor het servicesspoor van CallManager in Gedetailleerd staat, probeer dan het te wijzigen in "Fout".

Identificatie van proces verantwoordelijk voor schijf-I/O

Er is geen directe manier om het %IOWait gebruik per proces te achterhalen. Op dit moment is de beste manier om de processen op de schijf te controleren.

Als %IOWait hoog genoeg is om een waarschuwing voor koppeling te veroorzaken, controleer dan het waarschuwingsbericht om de processen te bepalen die wachten op schijf-I/O.

• Ga naar RTMT-procespagina en sorteer op status. Controleer op processen in de slaapstand van de ononderbreekbare schijf. Het SFTP-proces dat door TLC wordt gebruikt voor de geplande verzameling bevindt zich in de slaapstand van de Uninterruptible disk.

  

  Opmerking: het bestand PerfMon Log kan worden gedownload om de processtatus voor langere perioden te onderzoeken.

1. In de Real Time Monitoring Tool gaat u naar System > Tools > Trace > Trace & Log Central.

   

2. Dubbelklik op Verzamel bestanden en kies Volgende.

   

3. Kies Cisco RIS Data Collector PerfMonLog en kies Volgende.

   

4. In het veld Verzameltijd configureer de tijd die nodig is om logbestanden voor de betreffende periode te bekijken. Blader in het veld Bestandsopties downloaden naar uw downloadpad (een locatie waar u de Windows Performance Monitor kunt starten om het logbestand te bekijken), kies Zip Files en kies Voltooien.

   

5. Noteer de voortgang van de bestanden verzamelen en het downloadpad. Hier hoeven geen fouten te worden gerapporteerd.

   

6. Bekijk de Performance Log Files met de Microsoft Performance Monitor Tool. Kies Start > Instellingen > Configuratiescherm > Configuratiescherm > Systeembeheer > Prestaties.

   

7. Klik in het toepassingsvenster met de rechtermuisknop op Eigenschappen en kies Eigenschappen.

   

8. Kies het tabblad Bron in het dialoogvenster Eigenschappen systeemmonitor. Logbestanden kiezen: als gegevensbron en klik op de knop Toevoegen.

   

9. Blader naar de map waarin u het PerfMon Log bestand hebt gedownload en kies het perfmon csv bestand. Het logbestand bevat deze naamgevingsconventie:

   PerfMon_<knooppunt>_<maand>_<dag>_<jaar>_<uur>_<minuut>.csv; Bijvoorbeeld PerfMon_10.89.35.218_6_20_2005_11_27.csv.

10. Klik op Apply (Toepassen).

11. Klik op de knop Tijdbereik. Sleep de balk naar de juiste begin- en eindtijd om het tijdbereik in het PerfMon Log-bestand op te geven dat u wilt bekijken.

12. Als u het dialoogvenster Tellers toevoegen wilt openen, klikt u op het tabblad Gegevens en vervolgens klikt u op Toevoegen. Voeg Proces toe vanuit het vervolgkeuzevenster Prestatieobjecten. Kies Processtatus en klik op Alle instanties. Klik op Sluiten wanneer u de tellerskeuzes hebt gemaakt.

    

13. Tips voor wanneer u het logbestand bekijkt:

    • Stel de verticale schaal van de grafiek in op Maximum 6.

    • Stel scherp op elk proces en bekijk de Maximumwaarde van 2 of hoger.

    • Verwijdert processen die niet in Uninterruptible schijfslaap zijn.

    • Gebruik de optie voor markeren.

    

    Opmerking: Processtatus 2 = Uninterruptible disk sleep zijn verdacht. Andere statusmogelijkheden zijn 0-running, 1-slaap, 2-Uninterruptible schijfslaap, 3-Zombie, 4-Traced of gestopt, 5-Paging, 6-Onbekend

Code geel

De waarschuwing Code Yellow wordt gegenereerd wanneer de CallManager-service in de status Code Yellow wordt gestart. Zie Call Throttling en Code Yellow State voor meer informatie over de gele status van de code. De waarschuwing CodeYellow kan worden geconfigureerd om Trace-bestanden te downloaden voor probleemoplossingsdoeleinden.

De AverageExpectedDelay teller vertegenwoordigt de huidige gemiddelde verwachte vertraging om een inkomend bericht te verwerken. Als de waarde hoger is dan de waarde die is opgegeven in de "Code Yellow Entry Latency"-dienstparameter, wordt het CodeYellow-alarm gegenereerd. Deze teller kan één zeer belangrijke indicator van de prestaties van de vraagverwerking zijn.

CodeYellow maar totaal CPU gebruik is slechts 25% - Waarom?

Het is mogelijk voor CallManager om in de CodeYellow staat te gaan toe te schrijven aan een gebrek aan processormiddelen wanneer het totale gebruik van cpu slechts ongeveer 25-35 percenten in een 4 virtuele processordoos is.

Opmerking: als Hyper-Threading is ingeschakeld, heeft een server met twee fysieke processors vier virtuele processors.

Opmerking: op een server met twee processors is CodeYellow mogelijk op ongeveer 50 procent van het totale CPU-gebruik.

Waarschuwing: "De servicestatus is NIET actief. Cisco Messaging Interface

Als RTMT de Servicestatus verzendt, is DOWN. Cisco Messaging Interface. waarschuwing, moet u de Cisco Messaging Interface-service deactiveren als CUCM niet is geïntegreerd met een Voice Messaging System van een derde partij. Als u de Cisco Messaging Interface-service uitschakelt, worden verdere waarschuwingen van RTMT gestopt.

Gerelateerde informatie

• Spraaktechnologie-ondersteuning
• Productondersteuning voor spraak en Unified Communications
• Probleemoplossing voor Cisco IP-telefonie
• Technische ondersteuning en documentatie – Cisco Systems