6 Replies Latest reply on Feb 6, 2017 10:37 AM by Klaus Salger

    Handling Repository Cache

    Klaus Salger Expert
      Nachdem hier gerade über das Thema Staging bzw. den lokalen Cache und "was tun wenn die Platte auf dem Client vollläuft" diskutiert wurde, würde ich das Thema gerne nochmal etwas allgemeiner angehen.

      Wie sollte das Staging bzw. das Handling des lokalen Caches überhaupt funktionieren?

      - Info an Benutzer und Administratoren - das hatten wir gerade.
      Benutzer und Admins sollten informiert werden können wenn es Problem beim Staging gibt bzw. der Plattenplatz ausgeht.
      Per lokaler Meldung bei Anmeldung des Benutzers bzw. in regelmäßigen Abständen.
      Admins per Alert, z.B. per DSM Web / Infrastruktur-Monitoring und per Eventlog.
      Ganz allgemein: die bereits vorhandenen Komponenten aufbohren, damit Meldungen aus unterschiedlichen Quellen bei den unterschiedlichen Beteiligten ankommen. Und das natürlich konfigurierbar.

      - Cache Management verbessern
      Meine Vorschläge wären:

      1. Cache flexibler machen
      Ich möchte nicht dauerhaft die ganze Platte mit Cache belegen, ich möchte aber, dass bei Bedarf, d.h. temporär ein großer Teil des verfügbaren Platze für Cache benutzt werden kann. Der Cache muss danach halt auch wieder verkleinert werden.
      Damit könnte dann z.B. ein Riesenpaket gestaged werden, danach würde es dann aber auch zeitnah wieder gelöscht wenn es nicht in den regulären Cache passt.
      Dazu gibt es einen FR: ID 30249098 falls sich jemand dran hängen möchte.

      2. Platz reservieren
      Früher wurde eine Datei in der Größe des Caches angelegt. Damit war dann sichergestellt, dass der Speicherplatz im Cache auch verfügbar war.
      Heutzutage legt man nur noch fest, wieviel Speicher noch frei bleiben muss, also nicht von DSM verwendet werden darf. Dadurch wird vielleicht teilweise weniger Platz sinnlos verschwendet, es ist aber auch nicht garantiert, dass bei Bedarf welcher da ist.
      Mein Vorschlag wäre in Verbindung mit 1. wieder Platz zu reservieren um die Funktion des Stagings möglichst sicherzustellen und zu verhindern, dass der Platz anderweitig komplett verbraten wird. Temporär könnte dann zusätzlich (siehe 1.) auch nicht permanent reservierter Plattenplatz verwendet werden. Also z.B. ein paar GB fest belegen, einen Teil des Rests temporär benutzen wenn möglich.

      Was haltet ihr davon?
      Weitere Vorschläge?

      Ciao
        Klaus
        • 1. Re: Handling Repository Cache
          NicoS1 Master
          Hallo Klaus,

          ich persönlich finde das Cache Handling so wie es aktuell ist gut. Das die Festplatte voll läuft ist ja in der Regel kein Problem des Caches, sondern entweder der Anwender, die ihre Festplatte zu müssel, oder einer amoklaufenden Applikation, die ggf. die HDD vollmüllt (unter XP Beispielsweise gabs einen Bug, durch den .net Framework pro Stunde ein 25 MB Logfiles im SystemProfile erzeugt hatte).

          Ich versuch alles, um das was bereinigbar ist, durch diverse Prozesse zu bereinigen. z.B. Windows Update Cleanup, ein Batch das mir alle DSM Logs älter als 2 Wochen weglöscht uvm.

          Und so wie es aktuell ist, halte ichs persönlich für vorteilhafter. Wenn schon nicht genug Platz auf der Platte ist das Paket zu Stagen, ist oftmals auch nicht genug Platz auf der Platte ums zu installieren. Dementsprechend bringts mir ja nichts, wenn bei einer vollen Platte ein Paket in die 5 GB Cache pumpe die reserviert wurde, es aber dann auch nicht installiert bekomme ;-)

          Was aus meiner Sicht verbessert werden könnte ist die Reportbarkeit / Übersicht über den Fehler und die Transpranz zum User hin. In der neusten DSM Version kann ichs noch nicht beurteilen, aber in der "klassischen" ist es einfach so, dass ein Anwender bei einer Installation aus dem Shop nur eine Fehlermeldung übergebügelt bekommt, mit der ein normalsterblicher nichts anfangen kann, und als Administrator siehst du so etwas auch nur, wenn du die Policyinstanzen prüfst oder durch andere Methoden den Free-Diskspace überwachst. So etwas easy-to-use innerhalb von DSM zu haben wäre schon cool, da das Problem nicht gerade selten ist.

          Gruß
          • 2. Re: Handling Repository Cache
            SitzRieSe Expert
            Ich find den Defaultwert von 180 Tagen bei der Alterungszeit etwas lang, aber ansonsten find ich das Verhalten auch gut und der Wert kann ja Jeder für sich anpassen. Bisher klappt bei uns das Staging nur nicht wenn aus anderen Gründen die Platte voll gelaufen ist und das haben wir eigtl. nur bei einigen Power Usern und massiv auf virtuellen Desktops wo Windows Updates daran Schuld haben.

            Dort wächst das WinSxS massiv an und das ist leider nicht zu bereinigen.

            Gruß

            Alex
            • 3. Re: Handling Repository Cache
              Klaus Salger Expert
              OK, dass es wenig Sinn macht, ein Paket erst zu stagen und danach dann aus Platzmangel nicht mehr installieren zu können ist ein Argument.
              Da müsste man dann gleich mehr als den Platz für das Paket reservieren...

              Die "Alterungszeit" kann man verkürzen um den Cache auch ein bisschen schneller wieder zu räumen - das sind standardmäßig 120 Tage.
              Das ist allerdings auch der einzige Mechanismus, der den Cache wieder verkleinert, bis es soweit ist bleiben alle Pakete auf der Platte liegen oder werden direkt durch andere ersetzt.
              Und die Verkürzung der Alterungszeit sorgt für ein schnelleres Verkleinern des Caches egal wieviel drin ist, d.h. auch dann wenn es gar nicht nötig ist. Ich kann halt nicht sagen "verkleinere schnell bis auf 10 GB Cache oder 50 GB frei, danach dann langsam nach 120 Tagen oder so".

              Auf der einen Seite möchte ich genug Cache haben um möglichst immer installieren zu können.
              Auf der anderen Seite möchte ich aber nicht große Teile des Plattenplatzes dauerhaft für DSM-Pakete nutzen.
              Und schließlich möchte ich einen Re-Download von Paketen, die ich schon habe natürlich auch gerne vermeiden.

              So wie es heute ist tendiere ich auch am ehesten zur Verkürzung der Alterungszeit.
              Ansonsten bin ich bei der Konfiguration der Staging-Einstellungen aus den genannten Gründen immer hin- und hergerissen.
              Eine zusätzliche Konfigurationsmöglichkeit, die den Cache kurzfristig elastisch machen würde, fände ich günstig - natürlich so konfigurierbar, dass man sie auch nicht nutzen muss.

              Ciao
                Klaus
              • 4. Re: Handling Repository Cache
                NicoS1 Master
                Ich persönlich kann den praktischen Anwendungszweck eines "elastischen" Caches noch nicht wirklich greifen Klaus.

                Die Alterungszeit ist auch etwas, das bei mir ganz schnell auf 7-14 Tage runter gedreht wird, wenn ich eine neue DSM Umgebung aufsetze. Mehr, macht aus meiner Sicht nur an Standorten Sinn bei denen das Client-to-Client Staging aktiv ist, und kein Depot vor Ort (hab schon wieder den Namen der Funktion vergessen).

                Ich hoffe das gilt noch, aber vor langer Zeit wurde es in DSM ja mal so umgebaut, dass nachträgliche Userteile Grundsätzlich direkt vom Netz bezogen werden werden da "damals" ja das Paket komplett neu gestaged wurde wenn ein User sich das erste mal an einem Rechner angemeldet hat. Wenn sich an dem Verhalten nicht wieder was geändert hat (ich erinnere mich nicht, da was in den Patchnotes gelesen zu haben), erschließt sich mit außer beim Client-to-Client Staging kein wirklicher Grund.
                • 5. Re: Handling Repository Cache
                  _Mel_ Master


                  Auf der einen Seite möchte ich genug Cache haben um möglichst immer installieren zu können.
                  Auf der anderen Seite möchte ich aber nicht große Teile des Plattenplatzes dauerhaft für DSM-Pakete nutzen.

                  also so groß ist der verlust ja nicht, wenn plattenplatz, der andernfalls leer wäre für dsm pakete genutzt wird - der anwender sieht halt nicht so leicht wieviel platz ihm wirklich zur verfügung steht (im shop schon, aber das ist mMn recht gut versteckt)

                  aber wenn die anderen daten mehr werden, dann wird der cache ja automatisch kleiner, d.h. der platz ist nicht blockiert
                  • 6. Re: Handling Repository Cache
                    Klaus Salger Expert
                    @Nico: ah, OK, Du sagst also mehr oder weniger "wenn die Installation durch ist brauche ich auch das Paket im Cache nicht mehr".
                    Dann könnte man die Alterungszeit eigentlich auch auf 1 Tag heruntersetzen.

                    Finde ich im Prinzip auch interessant wenn die Benuzterteile direkt aus dem Depot gezogen werden können, was immerhin der Regelfall ist.
                    Das geht m.E. nicht
                    - in komprimierten Sites
                    - ohne Hardlinks im Install-Dir
                    - per https
                    - per Neighborcast

                    Für Reinstallationen und Deinstallationen muss das Paket halt dann neu gestaged werden.
                    Je schneller und billiger die Verbindung zum Depot umso leichter kann man mit einer erhöhten "Re-Download-Rate" leben.
                    Die Alterungszeit auf einen sehr kleinen Wert zu reduzieren ist dann jedenfalls bei den passenden Randbedingungen eine interessante Alternative.

                    @Mel: Also wenn ich alles bis auf 2GB oder so für den Repository Cache verbrate, dann ist erstmal nicht mehr als das verfügbar.
                    Kein Problem wenn ich akut nur 200MB brauche, dann fliegen demnächst Pakete aus dem Cache und ich habe wieder 2GB.
                    Wenn ich aber jetzt 3GB brauche?
                    Bei dem frei zu haltenden Wert etwas großzügiger zu sein und trotzdem nicht zu riskieren, dass dann Installationen nicht mehr laufen weil das Limit so hoch liegt fände ich schon angenehmer.

                    Ciao
                      Klaus