none
SCOM 2012R2: Konsolen Performance Probleme RRS feed

  • Frage

  • Hallo,

    Ich habe ein Problem mit der Performance meiner SCOM Konsole.

    Die Konsole wirkt sehr träge (lokal und Webkonsole), speziell bei zwei State Views die explizit nur den Health State einer Maschine und den Service State eines Prozesses monitoren.

    Ich habe folgende Schritte getätigt und kontrolliert:

    • Database Grooming von 5 auf 3 Tage gesetzt
    • Kontrolle der MDOP Einstellung und TempDB Filegröße am SQL Server
    • Datenbank RAM Reservierung begrenzt.
    • Kontrolle der Performance (perfmon), bis auf RAM Auslastung am MS1 nichts auffälliges.

    Es wurden ebenfalls auf beiden Management Servern die Ressourcen verringert:

    CPU: 16 Cores auf 4 Cores
    RAM: 30GB auf 16GB

    Die Performance ist ein wenig besser geworden jedoch immer noch nicht ausreichend verbessert.
    Mithilfe des Process Monitors (procmon) habe ich festgestellt, dass die Konsole jedes mal beim öffnen einer View, alle MPs in der lokalen User Registry durchsucht (sieht zumindest so aus).

    Kann mir diesbezüglich jemand helfen?

    mfg,

    Matthias


    Dienstag, 8. März 2016 08:15

Antworten

  • Hallo Matthias,

    hast du bereits versucht den lokalen Cache zu leeren?

    Versuch bitte zuerst den Cache so zu leeren:

    - Starte den Command Prompt als Admin und führe Folgendes aus:

    “C:\Program Files\System Center Operations Manager 2012 R2\Console\Microsoft.EnterpriseManagement.Monitoring.Console.exe” /clearcache

    -
    Öffne die Konsole erneut. Braucht diese auch so lange, um den Inhalt anzuzeigen?

    Versuche danach die Datei direkt zu löschen:

    - Navigiere zu: C:\Users\<user account>\AppData\Local\Microsoft\Microsoft.EnterpriseManagement.Monitoring.Console

    - Sichere die Datei "momcache.mdb" und lösche diese nachher. Hat sich was geändert?

    Zusätzlich würde ich dir empfehlen, falls deine Umgebung gross ist, dir den folgenden Artikel von Kevin Holman anzuschauen. Dieser ist ein "Must Read" wenn es um grössere Umgebungen (aber nicht nur) geht:

    Tweaking SCOM 2012 Management Servers for large environments

    Schau dir bitte auch das an:

    SCOM 2012x Console On Steroids? Try MDoP…

    MDoP kann eine grosse Ausworkung auf dem Performance haben....

    Und dann kommen wir zu der Datenbank...95% von den Performance Problemen sind im Zusammenhang damit. ... Also, das kann dir auch weiter helfen:

    How to troubleshoot Operations Manager DB performance problems

    Einige Tips meinerseits:

    - Anzahl der OpsMgr DB und TempDB Dateien = Anzahl an CPUs.
    - Recovery Model - SIMPLE
    - Korekte "Autogrowth" Einstellungen
    - Separate Drives für DB-Dateien, TempDB und Logs

    Das kommt vom:

    Optimizing tempdb Performance

    "

    • * You may have to adjust this percentage based on the speed of the I/O subsystem on which the tempdb files are located. To avoid potential latch time-outs, we recommend limiting the autogrow operation to approximately two minutes. For example, if the I/O subsystem can initialize a file at 50 MB per second, the FILEGROWTH increment should be set to a maximum of 6 GB, regardless of the tempdb file size. If possible, use instant database file initialization to improve the performance of autogrow operations.

    • Preallocate space for all tempdb files by setting the file size to a value large enough to accommodate the typical workload in the environment. This prevents tempdb from expanding too frequently, which can affect performance. The tempdb database should be set to autogrow, but this should be used to increase disk space for unplanned exceptions.

    • Create as many files as needed to maximize disk bandwidth. Using multiple files reduces tempdb storage contention and yields significantly better scalability. However, do not create too many files because this can reduce performance and increase management overhead. As a general guideline, create one data file for each CPU on the server (accounting for any affinity mask settings) and then adjust the number of files up or down as necessary. Note that a dual-core CPU is considered to be two CPUs.

    • Make each data file the same size; this allows for optimal proportional-fill performance.

    • Put the tempdb database on a fast I/O subsystem. Use disk striping if there are many directly attached disks.

    • Put the tempdb database on disks that differ from those that are used by user databases."

    Hoffe das hilft dir. Gruss,


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)


    Montag, 21. März 2016 13:43

Alle Antworten

  • Hallo Matthias Huetz,

    dieser Artikel könnte helfen. Sie benötigen mindestens UR6 for SCOM 2012 R2 – Step by Step

    Gruß

    Michaela


    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Dienstag, 8. März 2016 16:03
    Moderator
  • Hallo Michaela,

    Das habe ich schon umgesetzt, hat aber nur ein wenig geholfen. Ich bin von der Konsole am Server auf die lokale Konsole auf meinem Notebook umgestiegen und habe einen Performance Zuwachs bemerkt.

    Jedoch ist die SCOM Konsole immer noch um Welten langsamer als z.B.: die SCCM Konsole. Gibt es einen Trick den Start der Konsole zu verbessern und lässt sich das auf die Webkonsole übertragen?

    Danke im Voraus,

    Matthias

    Mittwoch, 9. März 2016 08:47
  • Hallo Matthias,

    hast du bereits versucht den lokalen Cache zu leeren?

    Versuch bitte zuerst den Cache so zu leeren:

    - Starte den Command Prompt als Admin und führe Folgendes aus:

    “C:\Program Files\System Center Operations Manager 2012 R2\Console\Microsoft.EnterpriseManagement.Monitoring.Console.exe” /clearcache

    -
    Öffne die Konsole erneut. Braucht diese auch so lange, um den Inhalt anzuzeigen?

    Versuche danach die Datei direkt zu löschen:

    - Navigiere zu: C:\Users\<user account>\AppData\Local\Microsoft\Microsoft.EnterpriseManagement.Monitoring.Console

    - Sichere die Datei "momcache.mdb" und lösche diese nachher. Hat sich was geändert?

    Zusätzlich würde ich dir empfehlen, falls deine Umgebung gross ist, dir den folgenden Artikel von Kevin Holman anzuschauen. Dieser ist ein "Must Read" wenn es um grössere Umgebungen (aber nicht nur) geht:

    Tweaking SCOM 2012 Management Servers for large environments

    Schau dir bitte auch das an:

    SCOM 2012x Console On Steroids? Try MDoP…

    MDoP kann eine grosse Ausworkung auf dem Performance haben....

    Und dann kommen wir zu der Datenbank...95% von den Performance Problemen sind im Zusammenhang damit. ... Also, das kann dir auch weiter helfen:

    How to troubleshoot Operations Manager DB performance problems

    Einige Tips meinerseits:

    - Anzahl der OpsMgr DB und TempDB Dateien = Anzahl an CPUs.
    - Recovery Model - SIMPLE
    - Korekte "Autogrowth" Einstellungen
    - Separate Drives für DB-Dateien, TempDB und Logs

    Das kommt vom:

    Optimizing tempdb Performance

    "

    • * You may have to adjust this percentage based on the speed of the I/O subsystem on which the tempdb files are located. To avoid potential latch time-outs, we recommend limiting the autogrow operation to approximately two minutes. For example, if the I/O subsystem can initialize a file at 50 MB per second, the FILEGROWTH increment should be set to a maximum of 6 GB, regardless of the tempdb file size. If possible, use instant database file initialization to improve the performance of autogrow operations.

    • Preallocate space for all tempdb files by setting the file size to a value large enough to accommodate the typical workload in the environment. This prevents tempdb from expanding too frequently, which can affect performance. The tempdb database should be set to autogrow, but this should be used to increase disk space for unplanned exceptions.

    • Create as many files as needed to maximize disk bandwidth. Using multiple files reduces tempdb storage contention and yields significantly better scalability. However, do not create too many files because this can reduce performance and increase management overhead. As a general guideline, create one data file for each CPU on the server (accounting for any affinity mask settings) and then adjust the number of files up or down as necessary. Note that a dual-core CPU is considered to be two CPUs.

    • Make each data file the same size; this allows for optimal proportional-fill performance.

    • Put the tempdb database on a fast I/O subsystem. Use disk striping if there are many directly attached disks.

    • Put the tempdb database on disks that differ from those that are used by user databases."

    Hoffe das hilft dir. Gruss,


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)


    Montag, 21. März 2016 13:43