/
Wie kann ich herausbekommen, warum das Documentviewer-TEMP plötzlich so voll ist?

Wie kann ich herausbekommen, warum das Documentviewer-TEMP plötzlich so voll ist?

Der Documentviewer besteht aus mehreren Komponenten. RenditonCache und REnditionPlus haben je ein eigenes TEMP-Verzeichnis. D.h. es gibt 2 TEMP-Verzeichnisse”

Alle Daten, die vom Documentviewer verarbeitet werden, werden temporär gespeichert. Es gibt Original, transformierte Formate (damit sie verarbeitet werden können), Ergebnisse aus Rendern, Volltextextraktion … Diese Dokumente werden generell ins TEMP kopiert. Ist der Job beendet, räumt der Documentviewer alles wieder weg.

Es kann aber sein, dass Fehler auftreten. Beispielsweise kann ein Job abbrechen, OutOfMemory auftreten etc. Dann bleiben die Daten im TEMP liegen bis der Aufräum-Job sie entfernt. Standardmäßig prüft der RenditionPlus alle 5 Minuten, ob etwas älter als 2 Stunden ist und entfernt es (das Verhalten ist konfigurierbar). 

nachfolgend:

Wichtig: Der Renditioncache räumt nie auf, da er nicht weiß, wann der Renditionplus komplett fertig ist! Daher räumt nur RenditionPlus das TEMP-Verzeichnis auf.
Beide TEMP-Verzeichnisse müssen immer gleich sein!

 

Schritt-für-Schritt-Anleitung

Gründe, warum das Verzeichnis volllaufen kann: 

  1. Die beiden Konfigurationsdateien zeigen nicht auf das gleiche TEMP-Verzeichnis (z. Bsp. weil jemand sie per Hand angepasst hat und nicht über die Admin-Oberfläche).

  2. Der Durchsatz an Dokumenten ist sehr hoch. 

  3. Jemand hat an der Konfiguration etwas geändert, z. Bsp. Auflösung. Damit werden übergroße Dateien erzeugt. 

  4. Es ist ein ungünstiger Viewer/Konverter eingestellt, der temporär zu große Dateien erzeugt.

  5. ein Virenscanner verhindert oder blockt das Löschen. 

  6. Jemand hat im Windows dem Dienstbenutzer die Lösch-Rechte entzogen. 

  7. Die Daten sind im WORK bereits so groß. Die Converter können diese Daten nicht verkleinern. 

  8. Das TEMP wurde auf einen UNC-Pfad gelegt, bei dem keine Löschrechte vergeben wurden

  9. Jemand hat per Hand Teile gelöscht. Es gibt Inkonsistenzen. Der Documentviewer kann einige kompensieren, aber nicht alle.

Generell sollten im TEMP alle Dateien verbleiben, die gerade in Bearbeitung sind, also alle aktuellen Daten. 

 

Generelle Analyse des TEMP: 

  1. Analyse: Was liegt darin und welche Mengen sind wie verteilt? 
    Am besten dazu ein Tool verwenden, dass den Plattenplatz zeigt, wie z. Bsp. TreeSizePortable. Ansonsten in das Verzeichnis per Explorer schauen oder per DIR-Befehl eine Liste erstellen. Beispielsweise so:

    DIR <documentviewer-data-verzeichnis>\TEMP\*.* /S > <gewünschter Zielpfad>\temp-liste.txt

  2. Das wurde bei Systemen schon festgestellt: 

    1. im TEMP direkt liegen mehr als 32.000 Dateien, die jünger als 2 Stunden sind  

    2. im TEMP direkt liegen mehr als 32.000 Dateien, die älter als 2 Stunden sind 

    3. im TEMP liegen zwar nur wenige, aber übergroße Dateien 

    4. im Unterverzeichnis MAGICKS liegen extrem viele Daten (auch Daten älter als 2 Stunden)

    5. Dateien sind im Windows gesperrt zum Löschen (Zugriffssperre durch Virenscanner oder NetApp)

    6. Virenscanner haben Teile der Documentviewer-Komponenten entfernt

    7. Es werden große ZIP-Dateien (500 MB mit mehreren tausend Einträgen) versucht zu rendern oder Videos (größer 1 GB).

  3. Diese Protokolle/Logs prüfen:

    1. RenditionCache-Log: Suchen nach generellem Fehlern, Beispiele aus dem TEMP suchen 

    2. RenditionPlus-Log: Gibt es Fehlermeldungen? Beispiele aus dem TEMP suchen. Was steht dazu? Gibt es Fehler beim Löschen ...?

    3. Monitoring-Log (osrenditioncache-jobmonitoring.log): Hier werden alle Jobs aufgelistet, die verarbeitet werden. Wie viele Jobs werden pro Stunde verarbeitet? Am besten alle im Zeitraum markieren und falls es zu viele Einträge sind, eine Hochrechnung ausführen.  Dazu (je nach Menge) 10 Minuten markieren. Beispiel: in 10 Minuten werden 3.000 Einträge verarbeitet. 3000 * 6 (6x10 Min. = 1 Stunde) = 18.000 pro Stunde, 2x 36.000 pro Stunde. D.h. wenn im TEMP mehr als 32.000 Dateien liegen, ist es ein Mengenproblem. Dann den Zeitraum verkleinern. 

  4. Konfigurationen prüfen (RenditionCache und RenditionPlus):

    1. Wurde etwas geändert? (z. Bsp. Änderungsdatum oder wurde das Format geändert, so dass der Documentviewer den Eintrag nicht mehr lesen kann) 
      Wurde ein ungültiger Pfad eingetragen (nicht Java-Schreibweise)?

    2. Falls ja: Welche Konfiguration wurde geändert, siehe auch
      Übersicht der Config-Dateien der Kerndienste ? 

  5. Virenscanner-Konfig prüfen, sofern möglich oder das Log:

    1. Wurden Ausnahmen konfiguriert? 

    2. Gibt es Meldungen zum Documentviewer-Temp-Verzeichnis, z. Bsp. Blocken von Komponenten oder in Quarantäne-Verschieben?

  6. Hat der Dienstbenutzer noch Löschrechte? Ggfls. als Dienstbenutzer anmelden (oder CMD als Dienstbenutzer starten und explizit mit “als Adminsitrator ausführen”) und versuchen eine ältere Datei im TEMP zu löschen. 

    CMD DEL <pfad zum Documentviewer-Temp>\<beispieldateiname>

 

Lösungsansätze:

  1. Die Rechte geben lassen von einem Administrator.

  2. UNC-Pfade vermeiden und falls doch nötig, Rechte der Freigabe prüfen/anpassen.

  1. Die beiden config.properties-Dateien (RenditionCache und RenditionPlus) müssen auf das gleiche TEMP-Verzeichnis zeigen. Beide Konfigurationen anpassen in Java-Schreibweise! 

  2. Bei allen anderen Konfigurationsproblemen:
    Warum wurde was geändert? Gibt es eine Änderung des Verhaltens, wenn man die Original-Dateien wieder einfügt? 
    Ein Kunde hatte beispielsweise die Wert bei Size geändert in der route.properties von Standardwert 96 auf 300. Das ist nicht nötig bzw. nicht die richtige Stelle gegen Probleme mit der Bild-Qualität. 

  3. Dienstneustart der Documentviewer nicht vergessen und Neuladen Indexservice nachdem der Documentviewer verfügbar ist! 

  1. Warum sind die Dokumente so groß? Wurden sie gescannt in einem ungünstigen Format?

  2. Können die Dokumente vor dem Import in enaio verkleinert werden? 
    Falls nicht, hilft es nichts. Dann ist die Datenmenge, wie sie ist und es muss mehr Plattenplatz bereitgestellt werden. 

D.h. es wird sehr viel und schnell verarbeitet. Der Standardwert von 2 Stunden bis zum Aufräumen kann zu lang sein.

  1. Die config.properties des RenditionPlus sichern und dann öffnen.

  2. Den Wert bei temp-maxValue anpassen auf eine sinnvolle Zeit. D.h. wenn das System 30.000 Dokumente pro Stunde schafft, kann eigentlich alles älter als 1 Stunde weg (eventuell sogar nach 1/2 Stunde). 
    Die Angabe ist in Millisekunden. Standardwert bei Versionen < enaio 10: 7200000, ab Version 10: 3600000

  3. Documentviewer-Dienst neu starten. 

  1. Kann der Virenscanner abgestellt werden? 

  2. Kann eine Ausnahmen beim Virenscanner eingestellt werden (Pfad oder Dokumenttyp, je nachdem, was erlaubt ist und welcher Typ gesperrt wurde)? 
    Typische Sperren liegen z. Bsp. auf Excel-Dateien oder Unterverzeichnisse oder Dateien im Verzeichnis TEMP\MAGICK.  

  3. Beim Bereinigen des Documentviewer-Temp hilft u.U. nur:

    1. Documentviewer-Dienst beenden 

    2. das Temp-Verzeichnis per Hand aufräumen bzw. den Inhalt löschen.

    3. im Schlimmsten Fall ein neues Temp-Verzeichnis erstellen und beim Documentviewer (am besten über die Admin-Oberfläche) konfigurieren. 

    4. Documentviewer-Dienst starten. 

  4. Falls der Virenscanner Komponenten des Documentviewers entfernt hat und diese nicht wiederherstellbar sind:
    a. Konfiguration des Documentviewers sichern
    b. letztes Documentviewer-Patch einspielen
    c. falls das nicht hilft: Documentviewer deinstallieren und neu installieren inkl. erneut konfigurieren

  1. Das Thema kann sehr vielfältig sein. Es ist möglich, dass ein bestimmtes Bildformat mit einer speziellen Komprimierung vorliegt. Die Converter müssen die Daten aber entpacken, um sie lesen zu können. 

  2. Hier kann nur geprüft werden, ob die Daten vor dem Import in enaio verkleinert werden können oder ein anderes Format bzw. Komprimierung erhalten können. 

  3. Ansonsten prüfen, welcher Converter verwendet wurde. Entweder siehe
    Wie kann man herausbekommen, welcher Converter verwendet wurde?

  4. Lösung könnte sein: einen anderen Converter zu verwenden und diesen als Custom-Converter einzubinden, z. Bsp.:
    Wie kann man einen Custom-Converter einfügen - GraphicMagicks? oder  
    Wie kann man einen Custom-Converter einfügen - ImageMagicks?

  5. Falls es große ZIP-Dateien sind oder Videoformate, kann das Rendern auch abgestellt werden, siehe Wie kann man für bestimmte Dokumenttypen das Rendern verhindern und anstelle X in der Vorschau etwas anderes anzeigen (z. Bsp. ZIP oder Video)?

  6. Ein Custom-Converter könnte fehlerhaft sein und Daten liegen lassen. Dann prüfen, ob dieser ausgetauscht oder entfernt werden kann.

 

Bitte beachten: Nach dem Neustart aller Documentviewer sollte auch der Indexservice neu geladen werden, sonst bleiben Volltext-Jobs in der CPQueue liegen. U.U. kann es auch nötig sein, den/die OCRServices neu zu laden. 

Verwandte Artikel