5 Replies Latest reply on Apr 4, 2017 4:40 AM by Klaus Salger

    DSM Konsole langsam

    RuedigerJ Specialist
      Hallo,

      unsere DSM Konsole ist mit der Zeit immer langsamer geworden.

      Wir hatten das schon mal. Dann haben wir ein "Aufräumtool" laufen lassen.
      Ich glaube, dass das aus den Powertoyz war und die Datanbank bereinigt hat.

      Das Ganze ist schon ziemlich lange her. Ich nicht mehr genau was es war und, ob es heute auch noch funktioniert.

      Kann mir da jemand weiter helfen?

      Danke
      Rüdiger
        • 1. Re: DSM Konsole langsam
          Frank.Scholer Master
          Hallo Rüdiger,

          ich denke, du suchst den "Database Tuning Advisor". Da gibt's bei uns im Blog einen Artikel dazu. Schau dir auf jeden Fall vorher mal den Thread hier an: http://www.enteo.com/showthread.php?t=15924

          HTH, Grüße Frank
          • 2. Re: DSM Konsole langsam
            SBRUTSCH Expert
            Hallo Rüdiger,

            ist interessant. Ich habe auch einen Kunden da ist seit Jahresanfang die DSMC langsam. Ist die Version 2016.1 die dort schon letztes Jahr upgedatet wurde.

            Wir haben zwar das ganze etwas verbessern können jedoch ist es immer noch nicht super schnell.

            Database Tunning und Aufbau eines zweiten BLS Servers hat hier ein wenig geholfen.

            Viele Grüße,
            Stefan
            • 3. Re: DSM Konsole langsam
              RuedigerJ Specialist
              Hallo,

              wir haben das Tool jetzt laufen lassen.

              Einzigstes Problem war:
              In der Doku von Frank steht, dass man auf einem SQL-Standard-Server die Datanbank offline schalten sollte. Das haben wir gemacht, konnten uns in dem Tool aber nicht mehr an der Datenbank anmelden. Also mußten wir sie auf Online lassen.

              Schneller geworden ist dann nichts.

              Kennt jemand noch ein paar Tricks zur Beschleunigung.

              Wir haben in unserem Labor schon einen eigenen SQL 2016 Server für die Datenbank genommen. Aber auch das hat es nicht gebracht.

              Gruß
              Rüdiger
              • 4. Re: DSM Konsole langsam
                SBRUTSCH Expert
                Hallo Rüdiger,

                erst mal ist es wichtig das du Zeitmessungen machst um nicht nur von einem Gefühl zu reden. Sonst wirst du auch anhand von Verbesserungen möglicherweise nichts fest stellen können.
                Und es ist wichtig zu wissen was langsam ist.

                1. Ist es das starten der Konsole?
                2. Das Arbeiten mit Paketen und der Packaging Workbench?
                3. Das Arbeiten unter Computer & Users?
                4. Nur wenn Policies angeschaut werden?
                5. Das arbeiten mit Policy Instanzen?

                Das sind wichtige Informationen um überhaupt weiter gehen zu können. Dann sind folgende Fragen zu klären:

                1. Auf welchen Serverplattformen laufen die Management Points und der Master Depotserver?
                2. Wie ist der Virenscanner eingestellt?
                3. Von welchen Client Plattformen ruft ihr die Konsole auf?
                4. Welche Netzwerkgeschwindigkeit haben die DSM Server und der SQL Server.

                Damit können wir dann erst mal eingrenzen ob es am Filezugriff liegt, am IIS oder am SQL Server bzw. die logische Auslastung des SQL Servers.


                Viele Grüße,
                Stefan
                • 5. Re: DSM Konsole langsam
                  Klaus Salger Expert
                  Also das mit "Datenbank offline schalten" ist ein Mißverständnis.
                  Der Punkt ist, dass die Indizes und die entsprechenden Tabellen bei Nicht-Enterprise Edition SQL Servern während des Rebuilds nicht verfügbar und damit offline sind.
                  Würde ein BLS also während eines Index Rebuilds versuchen auf die entsprechende Tabelle zuzugreifen, würde er einen Fehler bekommen.

                  Ich halte es für eine gute Idee, die Datenbank regelmäßig, d.h. per Maintenance Job zu prüfen und die Indizes wenn möglich per Reorg zu defragmentieren - das geht ohne Unterbrechung der Verfügbarkeit, also online.
                  Wenn nach dem Reorg die Fragmentierung immer noch über 30% ist, dann gibt's halt einen Rebuild.
                  Das kann man dann nächtlich oder am Wochenende laufen lassen bzw. in einem Zeitfenster, in dem nichts oder möglichst wenig los ist.

                  Wesentlicher als die zunehmende Fragmentierung der SQL Indizes ist m.E. aber das Wachstum der Policyinstanzen durch das Patching.
                  Da kommen immer mehr dazu. Wo man's am Anfang mal mit 30 Policyinstanzen zu tun hatte sind's jetzt 300...
                  Besserung ist an der Stelle immerhin in Sicht (mehr Kumu-Patches).
                  Um die Situation an der Stelle jetzt zu verbessern könnte ich mir vorstellen, dass es nützlich wäre, Patchpolicies zu entfernen sobald kein Computer mehr vorhanden ist, bei dem die entsprechende Lücke offen ist oder wenn eine Policy für einen superseding Patch vorhanden ist. Dadurch verliert man etwas Transparenz (was wurde bei wem wann gepatcht) aber damit kann man womöglich leben.

                  Analog dazu kann man auch andere nicht mehr benötigte Objekte entfernen, nicht benötigte Spalten und Policyinstanzen ausblenden, nach Möglichkeit Ansichten verwenden, in denen nicht alles und jedes erstmal angezeigt werden muss.
                  Das Handling von 20 Properties von 1000 Objekten dauert allemal länger als das von 5 Properties von 200 Objekten.
                  Im Übrigen braucht auch das Logging Ressourcen, den Loglevel zu reduzieren ist auch einen Versuch wert.


                  Wenn ich jetzt ernsthaft Performance-Optimierung machen würde, dann würde ich zunächst mit Hilfe des dsmc-Logs erfassen, was wie lange braucht und dann per PerfMon mal genauer prüfen, was zu den entsprechenden Zeiten auf den Systemen passiert (Auslastung / Latenzen von CPU, Storage, Netz, etc.). Also erstmal den Bottleneck finden und dann gezielt beseitigen. Und dann den nächsten Bottelneck finden ...
                  Dafür kann man aber gleich mal ein paar Stunden oder besser Tage einplanen.

                  Zum Thema Performance Troubleshooting gibt's übrigens auch einen Artikel im Support-Portal incl. PerfMon Data Collector Templates.

                  Ciao
                    Klaus