Monitoring en probleemoplossing met een hoge CPU voor Cisco Unified Communications Manager 6.0 met Real Time Monitoring Tool (RTMT)

Inleiding

Dit document biedt stappen om te helpen bij het bewaken en oplossen van problemen die te maken hebben met een hoog processorgebruik op Cisco Unified Communications Manager 6.0 met RTMT.

Voorwaarden

Vereisten

Cisco raadt aan dat u kennis hebt van dit onderwerp:

• Cisco Unified Communications Manager

Gebruikte componenten

De informatie in dit document is gebaseerd op deze agendapunten:

• Systeemtijd, Gebruikerstijd, IOWit, zachte IRQ en IRQ

• Waarschuwingen voor CPU-vastlegging

• Identificatie van proces dat de meeste CPU’s gebruikt

• Hoge IOWait

• Hoge IOWait door gemeenschappelijke deling

• Identificatie van het proces dat verantwoordelijk is voor Schijf I/O

• Cogeel

• Gebruik van de code geel maar totaal CPU 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, IOWit, zachte IRQ en IRQ

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

Deze termen vertegenwoordigen het gebruik van verslagen van RTMT CPU- en geheugenpagina's:

• %systeem: het percentage CPU-gebruik dat bij de uitvoering op systeemniveau (kern) is opgetreden

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

• %IOWait: het percentage van de tijd dat de CPU niet actief was toen deze op een uitstaand disk I/O-verzoek wachtte

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

• %IRQ het percentage van de tijd dat de processor het interrupte verzoek uitvoert, dat aan apparaten voor onderbreken is toegewezen, of een signaal naar de computer stuurt wanneer het klaar is met het verwerken

Waarschuwingen voor CPU-vastlegging

CPUPegging/CallProcesknooppuntCPUPegging-signalering monitor CPU-gebruik op basis van geconfigureerde drempels:

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

De waarschuwingsberichten omvatten:

• %systeem, %gebruiker, %nice, %iowait, %softirq en %irq

• Het proces dat het meeste CPU’s gebruikt

• De processen die wachten op onafbreekbare discs

CPU-signaleringen kunnen bij RTMT worden uitgevoerd door een hoger CPU-gebruik dan bij watermerkniveau. Aangezien CDR een CPU-intensieve toepassing is bij het laden, dient u te controleren of u de signaleringen in dezelfde periode ontvangt als wanneer de CDR is ingesteld om rapporten uit te voeren. In dit geval, kunt u de drempelwaarden op RTMT moeten verhogen. Raadpleeg Waarschuwingen voor meer informatie over RTMT-waarschuwingen.

Identificatie van proces dat de meeste CPU’s gebruikt

Als %systeem en/of %gebruiker hoog genoeg is om CpuPegging-waarschuwing te genereren, controleer dan het waarschuwingsbericht om te zien welke processen de meeste CPU gebruiken.

N.B.: Ga naar de RTMT-pagina en sorteer op %CPU’s om de processen met hoge CPU’s te identificeren.

Opmerking: Voor postmortemanalyse volgt het RIS-logbestand voor probleemoplossing PerfMon het proces %CPU-gebruik en volgt het op systeemniveau.

Hoge IOWait

Hoog %IOWait geeft I/O-activiteiten op hoge schijf aan. Bekijk deze:

• IOWait is het gevolg van het feit dat er veel geheugen is uitgewisseld.

  Controleer de %CPU-tijd voor splitsingen om te zien of er een grote mate van geheugen-wisselende activiteit is. Aangezien Muster ten minste 2G RAM heeft, is een overdosis geheugen waarschijnlijk het gevolg van een lek in het geheugen.

• IOWait is het gevolg van DB-activiteit.

  DB is hoofdzakelijk de enige die toegang heeft tot actieve partitie. Als %CPU Time voor actieve partitie hoog is, is er waarschijnlijk een grote DB-activiteit.

Hoge IOWait door gemeenschappelijke deling

De gebruikelijke (of logge) partitie is de locatie waarin sporen- en logbestanden worden opgeslagen.

Opmerking: Controleer deze:

• Middels overtrekken en inloggen: is er een activiteit voor het verzamelen van sporen? Als de aanroep verwerking wordt beïnvloed (dwz, CodeYellow), pas het schema van de spoorverzameling aan. Schakel deze uit als de zip-optie is gebruikt.

• Traceer-instelling op het Gedetailleerde niveau genereert CallManager nogal een beetje spoor. Als hoge %IOWait en/of CCM in de staat CodeYellow is en de instelling CallManager service sporen op Gedetailleerd is, probeer dan het te wijzigen in "Fout."

Identificatie van het proces dat verantwoordelijk is voor Schijf I/O

Er is geen directe manier om het %IOWait gebruik per proces te ontdekken. Op dit moment is de beste manier om de processen die op de disk wachten te controleren.

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

• Ga naar RTMT-procespagina en sorteren naar status. Controleer op processen in de slaapstand van de onafgebroken schijf. Het SFTP-proces dat door TLC voor geplande inzameling wordt gebruikt, bevindt zich in de onafbreekbare slaaptoestand van de schijf.

  

  Opmerking: Het PerfMon-logbestand voor probleemoplossing van RIS kan worden gedownload om de processtatus voor langere perioden te onderzoeken.

1. Ga in het Real Time Monitoring Tool naar System > Gereedschappen > Overtrekken > Overtrekken > Overtrekken en Centrifugeren.

   

2. Dubbelklik op Opnemen bestanden en kies Volgende.

   

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

   

4. In het veld Verzameltijd dient u de tijd te configureren die vereist is om logbestanden voor de desbetreffende periode te bekijken. Blader in het veld Bestandsopties downloaden naar uw downloadpad (een locatie waaruit u de Windows Performance Monitor kunt starten om het logbestand te bekijken), Zip-bestanden kiezen en Voltooien kiezen.

   

5. Merk op dat de bestanden zijn opgeslagen en gedownload. Hier dienen geen fouten te worden gemeld.

   

6. Bekijk de hoogwaardige logbestanden met het Microsoft Performance Monitor Tool. Kies Start > Instellingen > Configuratiescherm > Administratieve hulpmiddelen > Prestaties.

   

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

   

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

   

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

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

10. Klik op Toepassen.

11. Klik op de knop Tijdbereik. Om het tijdbereik in het PerfMon logbestand te specificeren dat u wilt bekijken, sleept u de balk naar de juiste begin- en eindtijd.

12. U opent het dialoogvenster Tellers toevoegen als volgt: klik op het tabblad Gegevens en klik op Toevoegen. Voeg proces toe in het vervolgkeuzevenster Prebjectief. Kies processtatus en klik op Alle instanties. Klik op Sluiten wanneer u de keuzes voor de tellers hebt gemaakt.

    

13. Tips voor het weergeven van het logbestand:

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

    • Stel scherp op elk proces en kijk naar de maximale waarde van 2 of meer.

    • Verwijdert processen die niet in een onafbreekbare diskslaap zitten.

    • Gebruik de optie markeren.

    

    Opmerking: Processtatus 2 = Ononderbroken disketslaap is verdacht. Andere statusmogelijkheden zijn 0-run, 1-slaap, 2-onafbreekbare disketslaap, 3-Zombie, 4-getraceerd of gestopt, 5-pagina, 6-onbekend

Cogeel

Het geel van de Code wordt gegenereerd wanneer de dienst CallManager in de Gele staat van de Code gaat. Raadpleeg voor meer informatie over de Code Yellow State het onderdeel Call Throttling en de Code Yellow State. De waarschuwing CodeYellow kan worden geconfigureerd om Trace-bestanden te downloaden voor probleemoplossing.

De GemiddeldeVerwachtEindtijd teller vertegenwoordigt de huidige gemiddelde verwachte vertraging om met om het even welke inkomende bericht te verwerken. Als de waarde hoger is dan de waarde die is gespecificeerd in de servicetechnicus "Code Yellow Entry Latency", wordt het alarm CodeYellow gegenereerd. Deze teller kan één belangrijke indicator van de vraag verwerkingsprestaties zijn.

CodeGeel maar totaal CPU gebruik is slechts 25% - waarom?

CallManager kan in de CodeYellow-staat gaan omdat er geen processorbronnen zijn, terwijl het totale CPU-gebruik in een vakje met 4 virtuele processors slechts 25-35 procent bedraagt.

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

Opmerking: Op dezelfde manier is CodeYellow op een server met twee processors mogelijk bij ongeveer 50 procent totaal CPU-gebruik.

Waarschuwing: "De servicestatus is VERLAAGD. Cisco Messaging Interface."

Als RTMT de status van de service verstuurt, is deze gedaald. Cisco-communicatie-interface. Raadpleeg het gedeelte Waarschuwingen, u moet de Cisco Messaging Interface Service desactiveren als CUCM niet geïntegreerd is met een Voice Messaging System van derden. Als u de Cisco Messaging Interface Service uitschakelt, stopt deze verdere waarschuwingen bij RTMT.

Gerelateerde informatie

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