Grosse PDF's - bearbeiten - System freeze

Hallo Liebe Community,

ich habe mich nun fast 2 Wochen intensiv mit paperless ngx beschäftigt

Meine beiden Instanzen laufen auf einer Debian 13 (Trixie) VM in Docker

10 CPU zugewiesen
16 GB RAM

NFS Mount => Synology

Problem:
Beim bearbeiten Bsp. Tags setzen Kontrolle..
PDF’s mit ungefähr 20 Seiten Text bzw. auch vereinzelt andere hängt sich Paperless auf.
WEB-GUI Zugriff nicht mehr möglich. Ich muss dann den gesamten Container neustarten.

NGNIX Proxy habe ich als Entlastung auch vorgeschaltet.

Ich finde so ist es leider kein Produktives System - und ich leider gerade unter Schlafmangel

PAPERLESS_OCR_MODE habe ich auch schon rumgespielt

Vielleicht habt Ihr einen Mega Tip für mich - da ecoDMS und andere teure Systeme eigentlich nicht in Frage kommen. Ich würde dann maximal nochmal zu mayan edms wechseln (anschauen) - aber dort habe ich nichts gefunden wegen XML (E-Rechnung) Verarbeitung. Dies habe ich mit Paperless ja schon hinbekommen.

Meine config von Paperless

pl_archiv_app:
    container_name: pl-archiv-app
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    restart: unless-stopped
    cpus: 10
    mem_limit: 16g
    depends_on: 
      postgres: 
        condition: service_healthy 
      redis: 
        condition: service_healthy 
      tika: 
        condition: service_healthy 
      gotenberg: 
        condition: service_healthy
    environment:
      PAPERLESS_DBHOST: postgres
      PAPERLESS_DBPORT: "5432"
      PAPERLESS_DBNAME: ${POSTGRES_DB_ARCHIV}
      PAPERLESS_DBUSER: ${POSTGRES_USER_ARCHIV}
      PAPERLESS_DBPASS: ${POSTGRES_PASSWORD}
      PAPERLESS_DBENGINE: postgresql

      PAPERLESS_ENABLE_FLOWER: "true"

      PAPERLESS_REDIS: redis://redis:6379/0   # Archiv
      PAPERLESS_REDIS_PREFIX: "archiv:"
      PAPERLESS_REDIS_CACHE_TTL: "600"

      PAPERLESS_TIME_ZONE: ${PAPERLESS_TIME_ZONE}

      PAPERLESS_OCR_MODE: "skip"
      PAPERLESS_OCR_LANGUAGES: ${PAPERLESS_OCR_LANGUAGES}
      PAPERLESS_OCR_LANGUAGE: ${PAPERLESS_OCR_LANGUAGE}
      PAPERLESS_OCR_ROTATE_PAGES: "true"
      PAPERLESS_OCR_ROTATE_PAGES_THRESHOLD: "12"
      PAPERLESS_OCR_OUTPUT_TYPE: "pdf"
      # PAPERLESS_OCR_USER_ARGS: '{"language": "deu+eng","rotate_pages": true,"deskew": true,"clean": true,"optimize": 3,"fast_web_view": 1,"redo_ocr": true,"invalidate_digital_signatures": true}'
      # PAPERLESS_OCR_USER_ARGS: '{"optimize": 1, "deskew": true, "fast_web_view": 1, "invalidate_digital_signatures": true}'

      PAPERLESS_COOKIE_PREFIX: plx1
      PAPERLESS_ALLOWED_HOSTS: "x.x.x.x,localhost,127.0.0.1"
      
      # Worker/Threads
      PAPERLESS_WORKER_TIMEOUT: "5400"
      PAPERLESS_WEBSERVER_WORKERS: "5"
      PAPERLESS_THREADS_PER_WORKER: "2"
      PAPERLESS_TASK_WORKERS: "2"


      # Filename und Ort der Datei
      PAPERLESS_FILENAME_FORMAT: "inbox/{{ created_year }}/{{ title|slugify }}"

      USERMAP_UID: ${USERMAP_UID}
      USERMAP_GID: ${USERMAP_GID}

      PAPERLESS_CONSUME_DIR: /usr/src/paperless/consume
      PAPERLESS_MEDIA_ROOT:  /usr/src/paperless/media
      PAPERLESS_EXPORT_DIR:  /usr/src/paperless/export
      PAPERLESS_EMPTY_TRASH_DIR: /usr/src/paperless/media/trash
      XML_ARCHIV_DIR: /usr/src/paperless/media/xml-archiv

      # Tika/Gotenberg Endpoints
      PAPERLESS_TIKA_ENABLED: ${PAPERLESS_TIKA_ENABLED}
      PAPERLESS_TIKA_ENDPOINT: ${PAPERLESS_TIKA_ENDPOINT}
      PAPERLESS_TIKA_GOTENBERG_ENDPOINT: ${PAPERLESS_TIKA_GOTENBERG_ENDPOINT}

      # LOG Managment
      PAPERLESS_LOGROTATE_MAX_SIZE: ${PAPERLESS_LOGROTATE_MAX_SIZE}
      PAPERLESS_LOGROTATE_MAX_BACKUPS: ${PAPERLESS_LOGROTATE_MAX_BACKUPS}

      PAPERLESS_CONSUMER_POLLING: "10"   # alle 10s nach neuen Dateien suchen
      PAPERLESS_CONSUMER_IGNORE_PATTERNS: '["\\.xml$"]'
      # PAPERLESS_CONSUMER_DISABLE: "false"
      PAPERLESS_CONSUMER_DELETE_DUPLICATES: "true"
      PAPERLESS_CONSUMER_RECURSIVE: "true"  # falls du Unterordner im consume nutzt
      # zum Debuggen:
      # PAPERLESS_LOGLEVEL: "DEBUG"

    volumes:
      - /srv/paperless/archiv/nas/archiv/consume:/usr/src/paperless/consume
      - /srv/paperless/archiv/nas/archiv/media:/usr/src/paperless/media
      - /srv/paperless/archiv/nas/archiv/export:/usr/src/paperless/export
      - /srv/paperless/archiv/data:/usr/src/paperless/data
      - /srv/paperless/archiv/scripts:/scripts:ro
      - /srv/paperless/archiv/addons:/addons:ro
    tmpfs:
      - /tmp:size=1G
    labels:
      - "paperless.container=webserver"
    # ports:
      # - "8080:8000"
    networks: 
      - paperless_frontend
      - paperless_backend

Vielen Lieben Dank im Vorraus :slight_smile:

Wie bist du denn zu dieser Konfiguration gekommen? Sieht mir auf den ersten Blick nach ChatGPT aus, kann das sein?

Allgemein würde ich empfehlen, mit einer einfachen, funktionierenden Grund-Konfiguration anzufangen und sich weiter durchzuarbeiten. Wir nutzen paperless-ngx mehr als produktiv mit Dokumenten über 100 Seiten und haben diese Probleme nicht.

Teste bei Bedarf gern die Demo, die wir öffentlich hosten, wenn du damit keine Probleme hast, liegt es an deinem Setup.

ChatGPT kann ich mir nicht vorstellen da es wirklich brauchbares ausgibt und sich damit auch Probleme wirklich analytisch lösen lassen.

Debian und RaspianOS scheidet auch aus als Container Variante ohne VM.

Ich verstehe diesen “VM-Trend” nicht da docker astrein läuft wenn man weiß was man tut.

Selbes problem Nativ ohne VM auch vorhanden ?

Das geht von der Performance selbst auf nem raspberry. Mit dem editieren.

Das mit dem editieren kannst du auch nen anderen Container machen lassen.

Hallo Stefan,

es ist natürlich eine Menge an Fragen und Bearbeitung aber auch gegen Prüfung mit ChatGPT eingeflossen.
Aber wie wir alle wissen ist die KI heute so und morgen so.

Deshalb natürlich musste ich vergleichen auch mit den docs, von paperless ngx.

Leider habe ich einfach weiter optimieren wollen.
Klar läuft Paperless NGX auch auf einer Syno im Docker (100% CPU bei OCR Last) - dies habe ich ja auch at Home aber ich wollte Paperless NGX auch in der Firma laufen lassen und nicht permanent Tagsüber die CPU so vergewaltigen :wink:
Deshalb die VM - Ressourcen auf unserm Hyper habe ich noch genug.

Es sind meistens Dokumente mit 30 / 40 Seiten - Inhalt Bilder Texte Ausweise usw.

Vielleicht habe ich das Problem falsch beschrieben

  • ich bearbeite ein Dokument 40Seiten
    Dokument öffnen manchmal ist rechte Seite Weiß - waiting
    Dann kann ich die Änderungen setzen - speichern - waiting oder reboot
    Wenn ich in einem anderen Tab weiterarbeiten möchte - nächste PDF - loading - weil dann ist der/die Webserver/UI von Paperless in den Knien.

Edit ich würde auch für eine saubere und stabile config - Geld ausgeben :slight_smile:

LG Basti

Wenn es Dir nur um das bearbeiten geht dann schau Dir mal stirlingpdf an, eventuell klappt das besser damit.

1 „Gefällt mir“

Guten Morgen Cooltux,

Habe ich glaube wieder falsch ausgedrückt- war dann doch ein wenig früh/spät gestern ^^

Paperless soll schon unser Archiv werden - das mit bearbeiten meinte ich Kontrolle - Tags und einsortierend Nachpflege.

Ich denke mal OCR liest wieder das gesamte Dokument obwohl „Skip“ dadurch laaaange Wartezeit oder Freeze

LG Qeib

Versuchs doch einfach Mal mit der Config die @RKuehne gepostet hat.

Ich würde auch sagen. Versuch erstmal eine Standard Konfig und mache später die Anpassungen Schritt für Schritt

Hi an alle,

erstmal danke das Ihr Hilfestellung gebt :slight_smile:
Also ich habe nun mal mein Setting angepasst und Mist einfach raus geschmissen.

Cpu/Ram Adressierung docker usw. ist raus habe die anderen Werte wie aus der docker-compose

meine Environment für Paperless

Hänge trotzdem an dem Problem was vielleicht mit dem NFS Mount (DS1819+) und
WD-WX61DC8L5H65 à 5.400 u/min Platten ohne / SDD für Lese und Schreibcache
zu tun haben könnte (Flaschenhals)

Ich öffne ein importiertes Gutachten ca. 25 Seiten stark
PDF Vorschau rödelt - obwohl ich dachte das er OCR Scan ja schon beim Import läuft und ich dies mit
PAPERLESS_OCR_MODE: „skip“ deklariert habe

wenn ich nun keine Geduld habe ^^ und einfach sagen wir mal Dokumente erneut öffne um die Übersicht zu sehen um vielleicht noch eines zu bearbeiten gleichzeitig - dann hängt die der Webserver von Paperless NGX - da er im Hintergrund bestimmt noch die Datei lädt bzw. verarbeitet.

Dachte auch liegt vielleicht an der Web Instanz aber eine andere IP(PC) konnte dies auch nicht mehr öffnen (Loading…)

Deshalb habe ich schon die
PAPERLESS_WEBSERVER_WORKERS auf 2 gesetzt

Habe eine weile mal die Stats mitlaufen lassen!

Nu deshalb kratze ich mir am Kopf…

So aber nochmal vielennnnnnnnn DANK ihr lieben - Ich werde weiter optimieren *knutsch

Lass es doch einfach mal 100% Nativ in Docker ohne den NFS-Mount laufen.

Das mit dem worker auf 2 setzen ist eher für Raspberry gedacht ( steht auch in der Dokumentation ).

Wie Docker nun die Resourcen verteilt weiß ich nicht und ich kann dir sagen ob SSD oder HDD ist total egal von der Geschwindigkeit.

Ich habe hier eine 918+ mit 4 WD-RED 2TB im Raid5 mit 2 SSD’s ( m2 ) und ein DIY-NAS auf Debian mit alten ausrangierten 750GB Samsung HDD’s und das Debian NAS ist schneller im verarbeiten des Imports mit den HDD’s als die Synology mit SSD’s.

Einfach mal 100 % Docker unter Debian mit Paperless-NGX direkt auf die Geräte Speicher laufen lassen und dann gucken was die Performance macht.

Wenn du den Docker Pfad ändern willst…