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…

Hi an alle

habe nun mein Setup grundlegend geändert

Synology 720+
16GB RAM
2x 2 TB SSD
2x 500GB SSD Cache

Container Manager inkl. Portainer und Ngnix

aber habe gerade festegestellt
PDF / 10 Seiten / à 6MB gross braucht für das erste Preview zum bearbeiten ca. 10 Sekunden
PDF / 22 Seiten / à 11MB naja dachte das Setup bringt was :frowning:


Vielleicht habt Ihr ja noch ein TIP - vielen Lieben Dank

Schon mal folgende Option bei den Einstellungen getestet?

ja dies habe ich auch
mein Problem ist ja nicht unbedingt das hängen wenn er die Datei klassifiziert bzw. ich nacharbeiten möchte und ich warten muss sondern das dann der komplette Webserver stuckt - also mal angenommen eine 2 Person möchte etwas bearbeiten - ist dies ja gar nicht möglich - ärgere mich gerade die 1000 EUR ausgegeben zu haben - anstatt mal die @IhDuepfe zu nehmen ein native Debian mit Xenon und vllt. 64GB und SSD und dies darauf aufzusetzen.

Habe nun wirklich denke in Performance investiert außer klar - hätte auch das Rack nehmen können mit Xenon für 1700 *arg aber naja habe ja noch alte Server hier bei mir liegen *sind nur sau laut ^^

Bin ein wenig enttäuscht über Paperless NGX von der Webperformance

Es wird Dir nicht helfen nehme ich mal an, aber ich habe mir mal seben die Mühe gemacht und ein eBook als PDF mit Bildern und Text mit 11,2 MB Größe in Paperless zu importieren.

Mein Paperless läuft auf einem Kubernetes Cluster mit kubeadm aufgesetzt. Meine Resourcen für den Container sind:

resources:
  limits:
    cpu: 1
    memory: "1536Mi"
  requests:
    cpu: 0.1
    memory: "128Mi"

Das Verarbeiten hat ungefähr 3 Minuten gedauert. Das laden dieser PDF Datei in den intern PDF Betrachter dauerte 2.20 Sekunden. Mit Hand gemessen.

Mein Setup sieht so aus:

Proxmox auf einem Dell Wyse 5070 mit Intel Pentium J5005 und 30GB RAM (Bios erkennt nur 30GB von 32GB)
Paperless läuft in einem LXC nativ, nicht im Docker.
Öffnen eines PDF mit 184 Seiten und 44,8MB größe dauert keine Sekunde. CPU-Auslastung im Proxmox Dashboard zuckt noch nicht mal. Ein top in der Konsole zeigt mir für zwei Sekunden unter 10% Auslastung.
Die Daten liegen auf einer NVME (bind mount, also direkt und nicht über Netzwerk).

Der in deiner Synology 720+ verbaute Intel Celeron J4125 ist ähnlich leistungsfähig. Daran kann es also eigentlich nicht liegen.
Wie ist das mit der RAM-Auslastung? Wenn die am Limit ist und er fängt an zu swappen wird das System ultra langasam.
Wie wird auf die Daten zugegriffen? Netzwerk (als NFS/CIFS einbindung) oder direkt auf das Device?

IMO ist da irgendwas an deiner Konfiguration im Argen, weil Paperless an sich mit vielen und/oder großen Dokumenten normalerweise kein Problem hat.

Verwendest Du in Deinem Setup einen Redis Server? Der unterstützt auch extrem wenn vorhanden.

Hi an alle,
und danke für eure Hilfe nach einer Lösung zu finden - selten so ein Forum gefunden/gesehen @Stefan

Also mein neues Setup beinhaltet das die Files erstmal direkt auf der Syno landen und danach synchronisiert werden. Also kein NFS Mount mehr @silbaer

Die Synology ist eigentlich auch nur für mein Paperless vorhaben gekauft worden :slight_smile:
Naja wenn dies nicht geht ^^ dann benutze ich Sie für andere schweinische Dinge *^^

Mein Setup habe ich wie folgt nun aufgebaut

version: '3.9'

paperless_frontend:
    name: paperless_frontend
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.240.0/24

paperless_backend:
    name: paperless_backend
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.241.0/24

services:
  # PostgreSQL is a powerful, open source object-relational database 
  postgres:
    container_name: pl-postgres
    image: postgres:16 # vielleicht lieber postgres:18 so wie bei mariushosting ?
    restart: unless-stopped
    networks: 
      - paperless_backend
    volumes:
      - /volume1/docker/portainer_stacks/postgres:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U paperless_archiv || exit 1"]
      interval: 1s
      timeout: 5s
      retries: 10
    environment:
      TZ: "Europe/Berlin"

# schneller, quelloffener In-Memory-Datenspeicher @mariushosting.com
  redis:
    container_name: pl-redis
    hostname: pl-redis
    image: redis:8
    restart: on-failure:5
    networks:
      - paperless_backend
    command:
      - /bin/sh
      - -c
      - redis-server --requirepass redispass
    security_opt:
      - no-new-privileges:true
    read_only: true
    volumes:
      - /volume1/docker/portainer_stacks/redis:/data:rw
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping || exit 1"]
    environment:
      TZ: "Europe/Berlin"

# The Apache Tika™ toolkit detects and extracts metadata and text from over a thousand different file types (such as PPT, XLS, and PDF). 
  tika:
    container_name: pl-tika
    image: apache/tika:2.9.2.1-full
    restart: unless-stopped
    networks: 
      - paperless_backend
    security_opt:
      - no-new-privileges:true
    environment:
      TZ: "Europe/Berlin"

# Gotenberg provides a developer-friendly API to interact with powerful tools like Chromium and LibreOffice for converting numerous document formats (HTML, Markdown, Word, Excel, etc.) into PDF files, and more!
  gotenberg:
    container_name: pl-gotenberg
    image: gotenberg/gotenberg:8
    restart: unless-stopped
    command: ["gotenberg", "--chromium-disable-javascript=true", "--chromium-allow-list=file:///tmp/.*"]
    networks: 
      - paperless_backend
    security_opt:
      - no-new-privileges:true
    environment:
      TZ: "Europe/Berlin"

# nginx ("engine x") is an HTTP web server, reverse proxy, content cache, load balancer, TCP/UDP proxy server, and mail proxy server.
  nginx:
    container_name: pl-nginx
    image: nginx:latest
    restart: unless-stopped
    networks:
      - paperless_frontend
      - paperless_backend
    ports:
      - "8080:8080"
    depends_on:
      - pl_archiv_app
    volumes:
      - /volume1/docker/portainer_stacks/nginx/conf.d:/etc/nginx/conf.d
      - /volume1/docker/portainer_stacks/nginx/logs:/var/log/nginx
      - /volume1/docker/portainer_stacks/nginx/cache:/var/cache/nginx
    healthcheck:
      test: ["CMD", "curl", "--fail", "http://localhost:8080"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s

# Paperless-ngx is a community-supported open-source document management system that transforms your physical documents into a searchable online archive.
  pl_archiv_app:
    container_name: pl-archiv-app
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    restart: unless-stopped
    # ports:
    #  - "8080:8000"
    networks: 
      - paperless_frontend
      - paperless_backend
    depends_on: 
      postgres: 
        condition: service_healthy 
      redis: 
        condition: service_healthy
    security_opt:
      - no-new-privileges:true
    # Liegt nun alles nicht im NFS sondern Lokal auf SSD
    volumes:
      - /volume1/docker/portainer_stacks/paperless/archiv/media:/usr/src/paperless/media
      - /volume1/docker/portainer_stacks/paperless/archiv/export:/usr/src/paperless/export
      - /volume1/docker/portainer_stacks/paperless/archiv/trash:/usr/src/paperless/trash
      - /volume1/docker/portainer_stacks/paperless/archiv/xml:/usr/src/paperless/xml
      - /volume1/docker/portainer_stacks/paperless/archiv/consume:/usr/src/paperless/consume
      - /volume1/docker/portainer_stacks/paperless/archiv/data:/usr/src/paperless/data
      - /volume1/docker/portainer_stacks/paperless/archiv/tmp:/usr/src/paperless/tmp
    environment:
      PAPERLESS_DBHOST: postgres
      PAPERLESS_DBPORT: "5432"
      PAPERLESS_DBNAME: "xxxx"
      PAPERLESS_DBUSER: "xxxx"
      PAPERLESS_DBPASS: "xxxx"
      PAPERLESS_DBENGINE: postgresql

      PAPERLESS_SECRET_KEY: "xxxxxxx"
      PAPERLESS_ENABLE_FLOWER: "true"
      PAPERLESS_REDIS: redis://:redispass@pl-redis:6379/0
      PAPERLESS_REDIS_PREFIX: "archiv:"
      PAPERLESS_REDIS_CACHE_TTL: "600"
      PAPERLESS_TIME_ZONE: "Europe/Berlin"

      PAPERLESS_COOKIE_PREFIX: "pl_archiv_"
      PAPERLESS_URL: http://10.11.8.5:8080
      PAPERLESS_ALLOWED_HOSTS: "localhost,127.0.0.1,10.11.8.5,archiv.plath24.intern"
      PAPERLESS_CSRF_TRUSTED_ORIGINS: "http://10.11.8.5:8080,http://localhost:8080"
      
      PAPERLESS_WEBSERVER_WORKERS: "2"
      # PAPERLESS_THREADS_PER_WORKER: "4"
      # PAPERLESS_TASK_WORKERS: "2"
      # PAPERLESS_WORKER_TIMEOUT: "3600"
      
      PAPERLESS_FILENAME_FORMAT: "inbox/{{ created_year }}/{{ title|slugify }}"

      USERMAP_UID: "xxxx"
      USERMAP_GID: "xxxx"

      # Pfade im Container
      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/trash
      PAPERLESS_CONVERT_TMPDIR: /usr/src/paperless/tmp
      XML_ARCHIV_DIR: /usr/src/paperless/xml

      PAPERLESS_EMPTY_TRASH_DELAY: "3650"

      # Tika/Gotenberg Endpoints
      PAPERLESS_TIKA_ENABLED: "true"
      PAPERLESS_TIKA_ENDPOINT: "http://tika:9998"
      PAPERLESS_TIKA_GOTENBERG_ENDPOINT: "http://gotenberg:3000"
      
      # Audit LOG
      PAPERLESS_AUDIT_LOG_ENABLED: "true"

      # Integritätsprüfung Dokumente
      PAPERLESS_SANITY_TASK_CRON: "30 0 * * SUN"

      PAPERLESS_CONSUMER_POLLING: "10"   # alle 10s nach neuen Dateien suchen
      PAPERLESS_CONSUMER_IGNORE_PATTERNS: "[\"@eaDir/*\", \"*.DS_Store\", \"\\\\.xml$\"]"
      PAPERLESS_CONSUMER_DELETE_DUPLICATES: "true"
      PAPERLESS_CONSUMER_RECURSIVE: "true"
      
      # zum Debuggen:
      # PAPERLESS_LOGLEVEL: "DEBUG"
      # PAPERLESS_DEBUG: "true"

Unterschied mariushosting.com

Seiten drehen

PAPERLESS_OCR_ROTATE_PAGES_THRESHOLD: 6

Worker

PAPERLESS_TASK_WORKERS: 1

Stelle ich ja im Backend bei Paperless ein

PAPERLESS_OCR_LANGUAGE: deu+eng

So sind meine aktuellen Werte - ansonsten sollte ich bei dir @Stefan ein live Meeting - buchen / dann siehst du den verpeilten auch mal Live der hier nervt ^^

Ich wünsche euch allen ein schönes Wochenende :_)

LG

Auf einer 920+ öffnet sich ein eingescanntes PDF mit 50MB in unter 5 Sekunden, Docker läuft auf einer SSD, 16GB RAM.
Ohne schreib und lese Cache, weil der eh nix bringt ausser „auf dicke Hose“ machen.

Ich würde mal den Stack von mariushosting auf der Synology testen, die laufer erfahrungsgemäß seht gut wenn man die Hinweise beachtet, nich zu viel dran rumfummelt und alles verschlimbessert.

Was passiert wenn du den Ngnix weglässt ?

Das ist das einzige was grob abweicht.

An der Hardware sollte es auch nicht liegen auch wenn nicht mehr aktuell… aber meine 918+ mit dem offiziellen Max RAM ( ich glaub 8 oder 16 GB ) hab ich ähnliches nie bemerkt.

Interessant wären mal die Dateien zum Testen für die Allgemeinheit wenn es allgemeine Handbücher oder so sind.

Ich hab glaub ich noch einige ebooks rumliegen die ich mal laufen lassen könnte.

Hallo an alle und danke für eure gemeinsame Hilfestellung.
Tja was soll ich sagen - nachdem die DS720+ remote gestern Abend (fehlerhafter StartScript von mir) nicht mehr erreichbar war - ist Sie wieder verpackt und geht auf Rückreise die SSD und M2 kann ich noch für andere Projekte gebrauchen. @Jake den SSD Cache habe ich nur geholt um einfach alles zu nutzen damit die „beste“ Performance kommt.

Ich bin heute morgen wieder zurück zu meinem ursprünglichen Setup

VM Debian - Konsole - Docker
20 Kerne
32 GB
SSD 500GB

NFS 4.1 mount mit Synology DS1819+ / Paketgrösse auf 32KB
mnt/media
mnt/trash
mnt/consume
mnt/export

und ich glaube das Entscheidende wo ich mich heute morgen noch belesen hatte war

PAPERLESS_WEBSERVER_WORKERS=<num>
The number of worker processes the webserver should spawn. More worker processes usually result in the front end to load data much quicker. However, each worker process also loads the entire application into memory separately, so increasing this value will increase RAM usage.

habe meine yml nur ein wenig getrimmt
Postgress 16 zu 18 und redis lastest

und siehe da klar das eine Datei 14 Seiten OCR belesen zum öffnen dauert - ABER nun mit

PAPERLESS_WEBSERVER_WORKERS: „6“

schießt er mir den Webserver nicht mehr ab :slight_smile:

lokal auf SSD (Debian wird ja jeden tag gesichert)
PostgresSQL
Redis
Paperless Data
Paperless Tmp

und ich muss sagen - SchlafMangel egal - um 3 hatte ich ein bis jetzt sehr gutes Setup
Mit was die 720+ / 16GB / SSD + Cache nicht mithalten konnte.

Vielen Dank für eure Unterstützung - ich belasse es nun erstmal bei diesem Setup

LG Qeib