Index geht kaputt, (wenn man neuen Tag einführt?)

Hallo!

Die gespeicherten Suchen gehen öfter mal ins Leere, weil der Index kaputtgegangen ist.

Den Grund für die Zerstörung des Indexes kenne ich nicht.

Ich weiß nur, dass es unter Anderem wiederholt auch im zeitlichen Zusammenhang mit der Einführung neuer Tags passiert ist. Ich werde das mal zu reproduzieren versuchen. Heute habe ich den Tag “Vorname” angelegt. Kurz darauf hat meine gespeicherte Suche

Erweitert: title:Praefix_*

nicht mehr funktioniert.
Nach einem vollständigen Reindex klappt sie dann wieder.
Aber ich mag nicht immer wieder mal einen vollständigen Reindex ausführen müssen, weil der 20 Minuten dauert und unsere Mitarbeiter in der Zeit nicht mit ihren gespeicherten Suchen Arbeiten können.

Neuerdings kommt mit dem Reindex eine weitere Komplikation hinzu - wieder nur ein zeitlicher Zusammenhang, ohne dass ich die genaue Ursache kenne: Das data bzw. data/index-Verzeichnisse gehört plötzlich root, und paperless kann nicht mehr schreiben.

Das ist vor Wochen mal passiert. Da war ich schuld. Ich habe versehentlich einen Docker/Paperless-Befehl in einem sudo-Fenster ausgeführt. Seitdem passe ich auf.
Gestern und heute ist es aber wieder passiert, obwohl ich seit mindestens einer Woche nicht mehr als sudo etwas gemacht habe. In beiden jüngeren Fällen lief unmittelbar vorher ein vollständiger Reindex.

Das mit den Berechtigungen lässt sich jedesmal mit

docker compose exec -u root webserver chown -R 1000:1000 /usr/src/paperless/data/index/

lösen. Besser wäre es natürlich, es würde gar nicht erst wieder auftreten.

Gruß
Andreas

Das klingt für mich wirklich nach einem Serverproblem bei dir.

Ich habe auch deinen letzten Post zum Anlass genommen, ein Testsystem mit über 50.000 Dokumenten aufzusetzen (ca. 2000 Wörter pro Dokument, zufällige Wörter aus dem Lorem Ipsum). Zwar sind die einzelnen Dokumente recht klein, weil es keine Scans sind, aber für die DB ist das relativ egal, da kommt es fast nur auf die erkannten Inhalte an.

Ich lade dich gerne ein, auf das Testsystem (läuft auf einer Testinstanz unserer paperless-cloud.com) zuzugreifen und Performance-Tests durchzuführen (neue Dokumente hinzufügen, suchen, etc.). Bei Interesse sag gerne kurz Bescheid, dann sende ich dir eine Mail mit den Zugangsdaten.

Hallo,

das klingt sehr interessant.

Ja, danke, gern.

Gruß

Andreas

Sehr gerne! Du hast Post (E-Mail). :wink:

Das Testsystem geriet ebenfalls aus dem Tritt, als ein paar hundert größere Dokumente (nicht zweiseitige, sondern 80seitige PDFs) hinzukamen.

Unser Produktivsystem: Als ich diesen Thread erstellte, galt für unser Produktivsystem: “paperless-ngx läuft in Docker auf Xubuntu-Server. Datenbank Postgres. docker-compose.yml so nah wie möglich am Standard. Derzeit (2025-11) 28tausend Dokumente und 9 User. “

Seit Anfang des Jahres habe ich von vorn angefangen:

paperless-ngx läuft in Docker auf einem Debian-13-Server. Datenbank Postgres 18. docker-compose.yml so nah wie möglich am Standard. Ich habe von den ursprünglich 28tausend PDFs 20tausend größere (dreistellige Seitenanzahl) PDFS (leider) NICHT mehr in Paperless. Die anderen 8tausend haben sich inzwischen auf knapp 11tausend PDFs erhöht. Die Seitennanzahlen sind überwiegend im einstelligen Bereich und fast immer unter 100. Es bleibt bei 9 Nutzern. Die Proxmox-VM hat 32 GB RAM und 32 GB Swap. ein vollständiger ReIndex, wenn ich ihn von Hand anstoße, dauert unter 5 Minuten:

time(docker compose run --rm webserver document_index reindex)

…

real    4m18,928s
user    0m0,154s
sys     0m0,124s


Der Index fällt auch in dieser Aufstellung alle cirka 2 Tage aus. Standardmäßig sollte er sowieso täglich um Mitternacht neu aufgebaut werden. Ich vermute ins Blaue, der Index geht verloren, wenn der morgendliche Posteingang verarbeitet wird. Zur “Verarbeitung” gehört auch, dass die Dokumente mit den Verarbeitungsfunktionen z.B. aufgetrennte, Seiten innerhalb des Dokuments nach hinten verschoben werden usw. - und das von mehreren Personen mitunter zeitgleich.

Vielleicht sollte ich 5 Minuten vor jeden vollen Stunde den Index per Cron-Job aufbauen lassen und die Kollegen darüber informieren, dass sie in diesen Zeiten kein Paperless zur Verfügung steht. Das wäre natürlich ein schmutziger Workaround.

Wenn ich unbedarft in die Protokolle sehe, erkenne ich nichts. Da sind so viele Einträge, die ich nicht verstehe, dass ich nicht erkenne, welcher davon aussagt, dass der Index kaputt ist.

Liest hier wer mit, der mit cirka 9 Leuten und 1000 neuen Dokumenten monatlich mit Paperless arbeitet?

(Der Vollständigkeit halber, das Problem ist nicht mehr aufgetreten: “Das data bzw. data/index-Verzeichnisse gehört plötzlich root, und paperless kann nicht mehr schreiben.”)