lwindolf / liferea

Liferea (Linux Feed Reader), a news reader for GTK/GNOME
https://lzone.de/liferea
GNU General Public License v2.0
822 stars 129 forks source link

liferea memory size #793

Open rich-coe opened 4 years ago

rich-coe commented 4 years ago

Investigate liferea runtime memory usage.

liferea seems heavy in memory usage than it needs to be. It's memory usage may be a contributor to #792.

I'm currently observing a virtual set of 4271904 and resident 648256. I'd like to reduce virtual set by at least half.

rich-coe commented 4 years ago

This is something I noticed in my usage of liferea and I'm investigating it.

nekohayo commented 4 years ago

What are the units of those numbers of yours, and how many feeds/items do you have? For what it's worth, Liferea 1.12.7 on my machine, which has hundreds of feeds and over 17 thousand unread items and a 100MB+ sqlite database, only consumes 88 MiB of "Memory" according to GNOME System Monitor, 158 MiB resident and 82.5 GiB virtual (which tells you that "virtual" memory is meaningless nonsense).

If you have similar numbers to me... I'll say that I really don't think 80-200MB of RAM is a concern these days (sure I have 24 GB of RAM on this 2008 workstation I'm still running, but even with el-cheapo entry-level machines these days you're hard-priced to find something with less than 4 or 8GB of RAM...)

rich-coe commented 4 years ago

Virtual is the total memory used by the process, resident is the memory in RAM. A large virtual size is one symptom of a memory leak.

The numbers came from top, which displays in KiB, unless larger, when it shows the larger unit.

This doesn't include the WebKitWebProcess(es) which have problems of their own.

nekohayo commented 4 years ago

If your liferea process has a resident size of ~630 MiB then yes that's a little bit odd compared to my ~80 MiB. Maybe you could analyze what's going on using Sysprof? If Liferea does indeed eat more than 500 MB of resident memory on your end then yeah, that's kinda suspicious. But if it's anything under that number, personally speaking (as a user) I wouldn't really lose sleep over it (but more power to you if you have the time to find and plug memory leaks if any :)

I do think the "virtual memory" numbers are meaningless and unactionable. This illustrates how ridiculous it seems to me:

2020-03-30 virtual memory

...the top ten processes "by virtual memory" on my system make it sound like I have over 830 GiB of memory available for allocation for processes, while my machine "only" has 24 GB of RAM and no swap. By the way, those processes in the screenshot are not even related to Liferea (which is not running at the time of the screenshot). Even if you dismiss WebKit and Firefox's "Web Content" processes as being bloated by the virtual memory metric, considering that a simple text editor like gedit requests 1.3 GiB of virtual tells me this metric has no connection to reality. So better stick to resident (or gnome-system-monitor's "Memory" column) to have a more meaningful picture.

mozbugbox commented 3 years ago

The real problem is the webkit. After following some complex web pages with the builtin browser for a while, the webkit could use some 1.3GB of RAM easily. At the same time, the liferea process uses only 160MB of RES.

I'm wondering if the memory used by webkit can be release somehow. Does recreate the WebKitWebView release the memory it holds?

stefanos82 commented 1 year ago

I have noticed this behavior a couple of months ago and decided to uninstall my distro's version liferea (1.14.4-3) (GNU / Debian testing 64-bit), and cloned the repo and built it myself to see whether it is a bug that has been already fixed.

The same issue remains the same and happened to me today again as other friends have mentioned above and it's really weird.

I opened my xfce4-taskmanager and noticed the following:

image

I said "this makes no sense", but what's mind boggling to me is how behavior of system notifications or any GUI redrawing process are affected...it delays to respond, be it moving my mouse or clicking on a button anywhere in a program or balloon popup.

As soon as I close liferea, everything returns back to normal.

I think it's both a fascinating and mind-numbing issue to say the least.

lwindolf commented 1 year ago

The caching model of WebkitGTK might be the problem. According to documentation default is "web browser" model. While there is also a "simple" one for other non-web page renderers (e.g. devhelp).

The interesting question for Liferea is what model to set. Some users might heavily use the internal browser and need the "web browser" cache model while others you read articles and would be fine without any caching.

stefanos82 commented 1 year ago

Excuse my ignorance, but after reading https://webkitgtk.org/reference/webkit2gtk/stable/enum.CacheModel.html#web_browser I cannot find where it says where exactly it saves the actual cached content.

Is it in memory, in a DAT file, or in an SQLite :memory: database?

lwindolf commented 1 year ago

@stefanos82 If you run file ~/.cache/liferea/WebKitCache/*/*/* you can see that documents are stored as is. For example:

/home/lars/.cache/liferea/WebKitCache/Version 16/Blobs/7C3B8F99BFD6A7BC79A4EE10DF53BE1EF29B3C9E:   JPEG image data, JFIF standard 1.01, resolution (DPI), density 72x72, segment length 16, baseline, precision 8, 150x150, components 3
/home/lars/.cache/liferea/WebKitCache/Version 16/Blobs/7D1F88DC31AA6505E49240D772E2FFD18FA4A554:   JPEG image data, Exif standard: [TIFF image data, little-endian, direntries=0], baseline, precision 8, 400x400, components 3
/home/lars/.cache/liferea/WebKitCache/Version 16/Blobs/DB8D41452486FD9F78A7E15A78E0F2B697901143:   JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, Exif Standard: [TIFF image data, little-endian, direntries=0], baseline, precision 8, 800x545, components 3
stefanos82 commented 1 year ago

Thank you @lwindolf

For some reason I thought it was saved in an SQLite file and I forgot to look in $HOME/.cache directory.