Hallo in die Runde,
seit dem Update von 2.10 auf 2.11. endet der Versuch den Exporter zu starteten, mit einem Fehler. Die Analyse ergab, dass der Prozess mit einem oom-kill beendet wird (out of memory). Das passiert auch dann, wenn alle Dateien aus paperless entfernt wurden. Zur Umgebung.
Paperless ngx läuft mit Docker auf einem Windows11 Rechner in wsl2.
Der Rechner hat 64 GB RAM und die Festplattenkapazität liegt auch weit außerhalb von gut und böse. Das Pagefile habe ich auf 96 GB vergrößert. Die VM läuft mit knapp 32 GB bereitgestellten RAM, das Swapfile von wsl ist 8 GB groß. Das postgresql(14)-Image hat knapp 600 MB, Gotenberg knapp 2,5 GB und paperless 2,0 GB Größe. Die Größe der Container liegen alle im 2 bis 3 stelligen KB-Bereich. Und die Daten (ca.20200 Dateien) in media-Ordner belegen 2,7 GB Plattenspeicher
Alle Tricks, die so im Internet zum oom-kill rumgeistern, machen es nur noch schlimmer. Die Infos aus der Analyse des Kill-Prozesses ergaben, dass der Prozess 46,8 GB Speicher angefordert hat (total-vm) und dass der anonyme Speicher 29,9 GB beträgt (anon-rss).
Wenn man alles, was in paperless an Daten zusammen kommt, zusammennimmt, 46,8 GB ergibt das nie.
Hatte schon mal jemand diesen Effekt und wenn ja, gibt es Lösungen?
Zur Zeit sieh es so aus, alles Löschen und neu Aufbauen, denn Backup ist nicht möglich.
Dann würde ich das als Fehlerticket in GitHub einstellen, vor allem, da du es an einer Version festmachen kannst.
Ansonsten bei 2.10 bleiben, bis es gefixt ist oder ein „hartes“ Backup der Datenbank machen statt über den Exporter.
Hallo,
zur Information.
Eine Versionsfrage war der Fehler nicht. Das System Document_Exporter akquiriert nur extrem viel Speicher und gibt ihn bei nicht mehr brauchen sehr zäh frei. Nachdem ich das swapfile auf 64 GB aufgedreht habe, ist der Fehler weg. Mitlaufende Speicherbelegungsbeobachtung kamen auf Lasten von knapp 50 GB. Was bei einem swapefile von 8 GB und 32 GB RAM-Zuweisung an wsl (Windows 11pro) dann zu viel ist. Was die Speicherlast auslöst, ist trotzdem nicht zu verstehen. Es werden zum Zeitpunkt des Fehlerauftritts nur noch die Daten in eine ZIP-Datei gespeichert. Mit allem anderen ist er schon fertig und wenn ich die volumes exportiere werden die gleichen Daten auch gezipt und der Fehler tritt dort nicht auf.
Gruß
Hartmut
P.S.: Irgendwie wollte GitHub mir kein Ticket gewähren, sodass ich dort nichts anmerken konnte.
Wenn es doch der Zip Prozess ist: läuft es durch wenn man den Parameter -z wegläßt? Wenn ja könnte es an einem Bug in der entsprechenden Python lib liegen. Als Workaround dann halt in einem script den Zip ausserhalb dufch ein anderes Programm mavhen lassen.
Hallo,
etwas unkonkret von mir ausgedrückt. Der ZIP-Prozess ist es nicht. Auch bei Export ohne ZIP passierte es, nachdem alles berechnet war (der Fortschrittsbalken zeigte 100 %) und die Daten nur noch „kopiert“ werden müssten (auch bei --data-only). Wenn man sich die Kommentare zum oom-killed error ansieht, legt das auch nahe, dass da irgendetwas „unsauber“ programmiert ist. (Speicher wird angefordert, aber nicht freigegeben, wenn er nicht mehr benötigt wird u.s.w.)
Gruß Hartmut
Nein, habe ich nicht. Wenn, dann dürfte es ja mit der Vergrößerung des Swapfiles auch nicht laufen. Ich habe zwar nicht alle Zwischengrößen von 8 GB bis 64 GB ausprobiert. Aber was ich feststellen konnte ist, dass eine Größe von weniger als Hauptspeichergröße immer den Fehler erzeugt hat. Ich habe auch noch ein reines Linux-System zu laufen (Intel N100, 16 GB RAM, 512 GB SSD, Linux Mint 22 / Ubuntu-24.04 in der Minimalkonfiguration und auf Docker Desktop als „Speicherfresser“ verzichtet), das gleiche Ergebnis.
Interessant, denn ich habe auch einen Nuc11 in der gleichen Konfig mit Ubuntu 24LTE am laufen. Allerdings habe ich keine 20.000 Dokumente. Und 20.000 Dokumente sind zwar für PLNGX 40000 (archiv + original), aber als PDF auch nicht sie die Masse. Welche Grösse hat denn dein media Verzeichnis?
Im Ganzen sind es knapp 7000 Originaldokumente mit weniger als 2 GB (Original + Archive zusammen) Speicherbedarf. Also eigentlich nichts außergewöhnliche.
Nein, das ist eher Kleinkram. Ich hätte jetzt beinahe einen Fehler in einer der Python libs in der Windowsversiion getipp, da es aber bei dir auch auf deiner N100 Kiste passiert bleibt wohl nur der Weg zu Githuib. Ich hab dazu keine Idee, ausser dass es etwas generelles bei größeret Dokumentenanzahl ist.