I opened two 40 MiB PDF documents and one 11 MiB and then scrolled down some pages in the 11 MiB document and noticed that I can watch memory usage grow quite a bit in System Monitor. Once I got to page 75 of 280 in this document, memory usage for Okular was 3.4 GiB.
I closed Okular and opened the same documents and scrolled down the 11 MiB one again and the results were the same.
Is this normal? I’ve not noticed it before.
Also, I first closed one of the large documents to see if memory would drop but instead Okular no longer appeared in System Monitor’s Overview and memory usage stayed about the same. I add this because I wonder if it is an issue in the way System Monitor iteracts with Okular. At that point, I navigated to the old version overview and Okular was listed; but when I closed the second document, Okular was removed from that list also although it was still open with the 11 MiB document still open.
I’m not suggesting anything is wrong but did not expect to use that much memory.
Thank you.
I should’ve done this first which is to open only the 11 MiB document and try it alone and that appears to be the issue. I thoght it has to do with the larger documents I had open at the same time but it appears not to be the case.
Any idea why this would occur? It’s a black and white PDF I downloaded from the archive.org web site several years ago.
Thank you. Out of curiosity, how can an 11 MiB document require over 3 GiB of cache? Are the pages compressed on disk and then expanded into memory as viewed, and cached such that if scroll back to a page it doesn’t need retrieved from disk again?
Also, it’s a book on Greek grammar in public domain but it is likely that every page is an image scan of the book and not really text converted to PDF.
Not every image displayed is a finished graphic. PDF is a vector-based page description language. I have seen PDFs with complex graphics, and those graphics were rendered in full.
I’m not sure whether there is any compression going on with the PDF format, but if your filesystem is btrfs, then yes, the document will be stored on disk in a compressed form.
Pdf has become a lot more complex and bloated over time. Compression, vector images, layers. In that particular case probably the greek letters are either high quality images uncompressed in ram or vector graphics.
Thanks. I don’t know what the document really is. It looks like a photo copy machine facsimile to me. I downloaded it in 2015 and the archive was sued and had to take down, they claim, around 500,000 documents. But I think this is the same one I downloaded Greek grammar.
If I open only that file in Okular and page down slowly to page 140 of 280, System Monitor shows Okular using 7.6 GiB of memory. At 180 it was 10.6 GiB and appears to have stopped consuming additional memory at 10.6 because at page 260 it is still 10.6 GiB.
I was just surprised that 11 MiB could be compressed/expanded by that ratio for what looks like nothing more than a photo-copy scan of an old book.
Perhaps, there is something odd about that file? I tried on a larger 40 MiB PDF that still appears to be a scan of pages but a cleaner appearing version and after 300 pages, it was at only 1.2 GiB.
It’s not important; I just wondered what was going on. Thank you.
Images can be compressed within the PDF; jpeg and tiff was most common in the early days; compressible and lossy.
Today, those who care about the PDFs they produce will avoid including raw scans (images) and convert from markdown, with graphic content being mainly photos.
By the way, there can also be a significant difference in the rendering (or even memory leak) between different readers. It is worth trying a different reader in such cases. Like the browser reader, or evince.
Yes, I added tiff only as an afterthought. The point is that formats tend to be a little more mature today; even jpeg. @teo raises another factor – the rendering software – I seem to recall that Okular has had it’s detractors over the years.
There is also an unfortunate practice of using existing 20-30 year old components with some projects – for convenience – rather than developing something more streamlined.
The description given of the memory usage certainly reminds me of software of that vintage.
Last time i experienced something like this was some years ago. With a GIS map. A city with a million+ population, every couple of buildings some grouping/colorful polygon overlay. That meant thousands of vectors. Some readers crashed, those that didn’t needed a minute to draw the screen after each move/scroll.
Out of curiosity, I opened the same PDF in Firefox and paged down and memory usage for Firefox increased by about only 0.8 GiB for all 280 pages. But how is it to be known if that means Firefox handles PDFs “better” or if it just does not allow for as large an in-memory cache for pages viewed?
One difference I noticed is that in Firefox each new page loads quickly and appears only clear, while in Okular each page loads first blurry and then comes into clear focus. But I don’t know what that means.
I went from a machine having 4 GiB of RAM to 32 GiB and am not used to it in terms of it being okay to observe an application consume 8 GiB when there is still 15 free after that. Perhaps Okular is just making use of the memory that is available.
I suspect Okular might be leaky and isn’t releasing memory as readily as some other renderers after use. Whatever the reason, RAM is there to be used – at least you had enough to contain it.
Sorry, eyes are tired here, I missed the “How” have you set up swap part. All I recall about swap was selecting a size when installing Manjaro. It is set to 17 GiB and I do not recall where I got that number. Dolphin says the disk size is 451.4 GiB. I think someone said that 17 is too small,
It has been working for me because I never leave much open in memory when hibernating. I have had a couple occassions in which the machine would not hibernate but then realized that either Firefox or Okular had consumed a lot of memory; and after closing the app. or an offending tab, the machine would hibernate.
Right now, System Monitor shows used swap at 579.9 MiB. If it matters, I haven’t rebooted for a few days.
17 GiB of swap should be fair for normal use – the general recommendation is “half the size of your physical RAM” if one will not be hibernating.
When hibernation is in the equation, it’s recommended to use a swap partition of at least the same amount as system RAM – say, 33 GiB in your case – this protects in the extreme case that physical RAM is fully utilised and needs to be swapped for hibernation.
A little space vs. always having to be aware of your RAM usage. I know what I’m more comfortable with.
Probably not. If you still only had 4/8 GiB total, that might be a cause for concern.
It all depends of how much you are actually swapping. For example, if you have swapped 3GB and want to hibernate you will have to add this to the total amount or real ram.
Practically speaking, the rule of a thumb earlier was 1.5x the amount of the ram. Nowadays i would still stick to this figure with 8 or 16GB RAM. For only 4GB i would go with factor 2, and set the swap to 8GB.
Above 16G physical ram the 1.5x rule starts to become overkill.
To sum it up: your 17G swap is a little small and risky if you have 16G ram, but a massive overkill if you have 8G ram. For the record, i am with 8G ram and i made 11G swap (probably had to make it 12) and i can safely hibernate a manjaro host+a windows guest vm inside.
