Funktion von Controlling: Speicherbelegung pro Vorgang?

Ich hatte angenommen, den Wert des belegten Speichers ( siehe Speicher in Produktionsumgebung ) auch hier auslesen zu können

Als Filter wähle (sinngemäß) ich “Alle Vorgänge berücksichtigen, die noch nicht in den Archivspeicher verschoben wurden”. Damit erfasse ich alle Vorgänge, die noch mindestens einen offenen Schritt im Workflow enthalten.

Die Trefferanzeige sieht dann (verkürzt) so aus:

Die Trefferanzahl ist korrekt. Allerdings stimmt die “Gesamtgröße der Master-Dateien” nicht. In der Liste werden Vorgänge mit “Größe der Master-Dateien” 0 B angezeigt, die defintiv mehrere GB an TIFF-Dateien enthalten.

Stimmt meine Annahme, dass der Wert hier erst berechnet/ angezeigt wird, wenn der Vorgänge im Workflow-Schritt “Metadatenerschließung” angekommen sind?

Beste Grüße, Andreas

Wenn ich richtig liege, braucht es ein Update des Datenbank-Caches.
Probiere das für einen beliebigen Vorgang, der 0 B anzeigt, einmal aus mit dem folgenden GoobiScript: (ich habe gestern den gesamten Cache mit nur 8000 Vorgängen aktualisiert, das hat 6 Stunden gedauert.)

---
# This GoobiScript ensures that the internal database table of the Goobi database is updated with the status of the workflows and the associated media files as well as metadata from the METS file.
action: updateDatabaseCache
1 Like

Du hast recht, das war der Grund. Vielen Dank für die schnelle Hilfe. Jetzt müßte man das skript nur noch an geeigneter Stelle in den Workflow einbinden, um es nicht immer manuell starten zu müssen.

@steffen und @robert.sehr , wo wäre das denn am sinnvollsten? Direkt nach dem übertragen der Masterdateien in Goobi workflow? Oder nach dem erzeugen der Derivate?

ich werde es nach “Image Convert” o.ä. Aufgabenschritten reinhängen. (und vlt. auch als abschliessender Schritt nochmal wiederholen) Veränderungen des Speicherbedarfs durch Metadaten-File-Bearbeitung können unter den Tisch fallen.

2 Likes

Ich hab mir das bei uns angesehen. Im Großen und Ganzen stimmen die Zahlen in dem Report. Deshalb frage ich mich, wie es passieren kann, dass der DB-Cache so asynchron wird und das Update gezielt angestoßen werden muss. Sollte das nicht nur in Ausnahmefällen nötig sein? Oder habt ihr Workflowschritte, bei denen das systematisch passiert?

also bei uns sind einmal grundsätzlich immer 0 Byte Speicherverbrauch bei allen Vorgängen. Wir haben S3-Storage, da ist immer alles anders :wink: - daher verwundert es mich nicht, dass es nicht automatisch berechnet wurde.
Aber klar, eigentl. wäre dieser Cache natürlich schön, er würde immer wieder an verschiedenen Stellen automatisch neu gefüllt, bei allen Schritten mit Schreibprozessen etc.

2 Likes

S3 ist natürlich anders :smiley:
Aber die Fälle, wo ich sehe, dass es auseinanderläuft geschehen meiner Beobachtung nach dort, wo »an Goobi vorbei« mit Skripten oder direkt im Dateisystem herummanipuliert wird (da bin ich in unserem Fall aber auch selber schuld).

2 Likes

Ein Hinweis von @robert.sehr in der Sache hat mir gerade ein großes Stück weitergeholfen. Man kann das “Problem” auch ohne ein manuell ausgelöstes Goobi-Script lösen. In der Vorgangsvorlage bei den Aufgabendetails (aller relevanten Schritte) einfach hier ein Häkchen setzen:

2 Likes