paperless_share VS pgbadger

I've been using Paperless for several years now very happily and can recommend it over my previous system, also Google Drive. During the transition I found it helpful to set up a cron which (A) made an export of Paperless and (B) uploaded that export to a Google Drive folder.

One feature which seems to be quite a nice improvement (speculating as I haven't upgraded yet) is consumption templates [0]. My workflow involves an ADF scanner with an Android application, sharing the scanned PDF with Paperless Share [1] and then it's uploaded to the server via API. It seems that consumption templates will enable adjusting tags/sharing settings/permissions of a document at ingestion time based on where it's ingested from.

[0] https://github.com/paperless-ngx/paperless-ngx/pull/4196

[1] https://github.com/qcasey/paperless_share

Für Android: Beliebige Scanner App und https://github.com/qcasey/paperless_share

Paperless Share (version 2008): Share documents with your Paperless server

It really is. It was painless to setup and worked perfectly using Paperless Share. Documentation is also phenomenal and had a huge boon in the form of recommended workflow to help people getting started (me).

I use Swiftscan and Paperless Share with my Android phone. Works well.

It might also help to use pgbadger or something similar to process your postgres logs and see whether some event is aligned with your outages.

Interestingly, when a place does get to the point where the single instance has capacity issues (after upgrading to EPYC and lots of flash drives) then other non-obvious stuff shows up too.

For example, at one place just over a year ago they were well into this territory. One of weird problems for them was with pgBadger's memory usage (https://github.com/darold/pgbadger). That's written in perl, which doesn't seem to go garbage collection well. So even on a reporting node with a few hundred GB's of ram, it could take more than 24 hours to do a "monthly" reporting run.

There wasn't a solution in place at the time I left, so they're probably still having the issue... ;)

First of all I used a profiler (pgbadger and netdata) to figure out where the lags were coming from. I then tried the usual stuff (increasing shared_buffers, max_wal_size, min_wal_size from their ultra low defaults), but the biggest performance gain came from moving the database from eMMC to a mechanical hard drive :-D

Look into PgBadger (a log parser/analyser): https://github.com/darold/pgbadger