Quote:
Originally Posted by rkomar
I am running 64-bit linux, but because of Illegal Instruction errors, I have been running the 32-bit version of k2pdfopt-2.53. Unfortunately, the first command above fails after a dozen pages because k2pdfopt cannot allocate enough memory (it fails while trying to allocate a 273 MB buffer). The resident memory usage must have hit the limit for 32-bit programs. I have 24 GB of RAM in the system, so this is a frustrating roadblock.
The memory usage for that first command is way higher than for the command given in post #6. Is it "-ocrd p" that causes the usage to skyrocket?
|
Try adding
-nt 1. This will queue up only 1 image at a time for OCR. Otherwise k2pdfopt tries to queue up multiple images so that it can perform multi-threaded OCR, which is faster, but consumes much more memory. BTW, even with -nt 8, k2pdfopt used at most 1.5 GB RAM on my system. Seems strange it should run out if you have 24 GB available.
On a virtual Fedora 37 machine with 16 GB RAM, with k2pdfopt v2.54, I get the following results from this command:
k2pdfopt -nt <XX> -mode copy -dpi 600 -ocr t -ocrd p src.pdf
32-bit, <XX> = 8 failed on page 13 trying to allocate a 1-GB bitmap
32-bit, <XX> = 4 same result as above
32-bit, <XX> = 2 completed successfully
64-bit, <XX> = 8 completed successfully (consumed up to 5.5 GB during the run)
With k2pdfopt v2.53:
64-bit fails in Fedora 37 because it was compiled on an earlier Linux kernel.
32-bit, <XX> = 8 and 4 fails on page 13 trying to allocate a 270-MB image
32-bit, <XX> = 2 fails on page 14
32-bit, <XX> = 1 fails on page 17
There is a known memory leak issue in v2.53. See the
fix in v2.54.