Obwohl ich das Excel-Plugin viel verwende, habe ich eine Konfiguration noch immer nicht richtig im Griff, die ich bei Projekten mit sehr vielen Vorgängen und in Summe grossen Datenmengen aber gut gebrauchen könnte.
Aktuell kopiert mir das Plugin alle zu importierenden Bilder in den /tmp Ordner; ich glaube mich aber erinnern zu können, dass dem Plugin beizubringen ist nur ein bestimmte Anzahl an Vorgängen zu importieren (nicht mit rowStart / rowEnd, sondern Warteschlangen-Bezogen?) um dann erst fortzufahren; womit ich leicht grosse Projekte mit einem Import anstossen kann, mir aber keine Sorgen machen muss, dass der Speicher von /tmp ausgeht.
Hi Christian,
warum ist es denn ein Problem, die Daten in den tmp-Ordner zu laden? Wenn der intern auf dem gleichen Speicherbereich liegt, wie der Ordner metadata, dann würde die Speichermenge ja nur in dem Umfang ins Gewicht fallen, wie sie sowieso für die neu einzuspielenden Daten benötigt werden.
Mit anderen Worten: Sie landen zunächst in tmp und werden dann nur bewegt nach metadata. Für die Festplatte (bzw. den Speicherbereich) ist es doch aber die gleiche Größenordung, die damit belegt ist.
Oder verstehe ich was falsch?
Liebe Grüße,
Steffen
bei uns ist das doch anders. weil die master-files von /tmp dann nach s3 erst geschoben werden; die server-platte selbst ist nicht besonders gross; weil ja nur temporär belastet.
ich hatte es einmal schon so konfiguriert, dass der excel-importer immer nur die maximale Zahl an Vorgängen gemäss der goobi_config.prop MaxQueue Number in /tmp hatte, und wenn die abgefrühstückt waren, kamen die nächsten.
Aber so recht bekomm ich das nicht mehr hin; <runAsGoobiScript>
macht bei mir sowohl mit true als auch false keinen Unterschied.
@robert.sehr Fällt Dir hierzu ein, was man ggf. machen könnte, um das mehr in Häppchen zu verarbeiten und die Platte nicht so vollzuschreiben?
Ah, bezüglich meiner “Behauptung”, ich hätte das Plugin schon einmal so konfiguriert, dass es beim Import nur die maximale Anzahl definiert für die langsame Warteschlange im FileUpload reinzieht muss ich revidieren. Der Speichermangel, den ich früher hatte, war nicht bedingt durch den FileUpload, sondern erst im folgenden Schritt beim PDF-Splitting, wo das Plugin im schnellen Fall alle Vorgänge versucht parallel zu splitten und das hat dann nicht geklappt.
Aber FileUpload immer alles sofort. Da muss ich mir aktuell mit rowStart/rowEnd helfen; das ist aber natürlich langweilig, mühsam, fehleranfällig, nervig etc. etc. 