After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 796419 - High memory usage
High memory usage
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: general
3.28.x
Other Linux
: Normal major
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2018-05-26 21:00 UTC by Marek Samec
Modified: 2018-11-28 21:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Marek Samec 2018-05-26 21:00:28 UTC
When evolution starts it takes about 98 - 140 MB ram. But if there is lot of HTML heavy new emails, the memory usage grows. After browsing through 20+ HTML emails (I have used "Load remote content" for some of them). The memory usage rose to about 380MB and the system performance was impacted even though I still had around 900MB free memory availabkle.

I have version 3.28.1-2 running under Lubuntu with Cinnamon environment.
Comment 1 André Klapper 2018-05-27 22:24:32 UTC
I don't see a bug here, as heavy stuff requires heavy RAM?

(If you would like to hunt down potential memory leaks, Valgrind logs are welcome.)
Comment 2 Milan Crha 2018-05-28 13:48:32 UTC
Thanks for a bug report. I agree with Andre, valgrind is a good tool to start with when searching for memory leaks. You might run it with these three commands:

   $ export GIGACAGE_ENABLED=0
   $ export G_SLICE=always-malloc
   $ valgrind --num-callers=30 --leak-check=full --show-leak-kinds=definite \
        evolution &>log.txt

Please make sure that you've installed debuginfo packages for at least evolution-data-server and evolution, but the more other packages (libsoup, glib2, gtk3 and so on) the better. Without them the valgrind log will be rather useless. please note that evolution will be significantly slower, due to all the memory checking.

When I've been trying this command I noticed a related leak which I fixed with the below commit. This particular leak didn't cause any significant memory usage, at least not here. Note that WebKitGTK+ is split into the main process (in this case Evolution) and a WebKitWebProcess and also WebKitNetworkProcess. The WebProcess is responsible for page rendering and evolution talks to it over D-Bus. It also provides it with downloaded remote content when needed, which can be loaded into memory first. That can also mean, as a side effect, that the memory is allocated by the system, but it is not freed for other processes immediately, even the code itself already freed it.

Created commit acf1095e15 in evo master (3.29.3+)
Created commit 96d027f290 in evo gnome-3-28 (3.28.3+)
Comment 3 Marek Samec 2018-06-04 21:10:46 UTC
André, Milan thanks for suggestion I will install valgrind and come back here with my results.
Comment 4 Maciej Mrozowski 2018-11-23 15:44:09 UTC
I agree with Andre, 380MiB is nothing, though perhaps Evo could provide some option for "how hot you want your _memory_ email cache to be".

Because.. below is my typical Evo memory usage. Resident 1.1GiB after some emailing is all fine for me (starts with ~90MiB).
But just for the lulz take a look at VIRT:

top - 16:24:21 up  4:17,  4 users,  load average: 2,06, 1,76, 1,28
Tasks: 263 total,   1 running, 262 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5,0 us,  3,1 sy,  0,0 ni, 91,2 id,  0,0 wa,  0,6 hi,  0,2 si,  0,0 st
MiB Mem :   7666,9 total,   1389,9 free,   3041,2 used,   3235,8 buff/cache
MiB Swap:   9216,0 total,   9212,7 free,      3,2 used.   3998,2 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                                                                                                                                                 
 2125 mrozowsk  20   0  100,2g   1,1g  99612 S   3,3  14,5   7:00.08 evolution

I have 20GiB worth of emails on that server (as reported on OWA) so it's a lot.
That over 83GiB VIRT allocation happens right after starting Evo.

Disclaimer: I'm not complaining about Evo performance here, just mentioning this VIRT usage as curiosity.
Comment 5 Milan Crha 2018-11-26 09:50:03 UTC
What is the WebKitGTK+ version you have installed, please? (It can be webkitgtk4 or webkit2gtk4 package, depending on the distribution and its version). The thing is that I thin since 2.20 it uses something called gigacage, which allocates a lot of virtual memory. It can be disabled when you you evolution as:

   $ GIGACAGE_ENABLED=0 evolution

which also causes some prints on the console if you make it right. This is also needed when running evolution under valgrind, because valgrind doesn't like such large memory allocation.

I'm not sure how this gigacage works, but I think a corresponding WebKitWebProcess-es also allocate it, similarly as other WebKit and evolution(-data-server) processes, but I can be wrong here.
Comment 6 Maciej Mrozowski 2018-11-28 14:21:39 UTC
Indeed, in my case that "gigacache" ise enabled by default.
@Marek
Just in case run Evo with GIGACAGE_ENABLED=0 as well, to eliminate some this Webkit nuance from equation.
Comment 7 Maciej Mrozowski 2018-11-28 14:23:25 UTC
"cage", it's security feature apparently:

https://labs.mwrinfosecurity.com/blog/some-brief-notes-on-webkit-heap-hardening/
Comment 8 Milan Crha 2018-11-28 14:27:24 UTC
(In reply to Maciej Mrozowski from comment #7)
> "cage", it's security feature apparently:

Right, it's a security feature, thus it's enabled "by default". :)
Comment 9 Marek Samec 2018-11-28 21:31:24 UTC
I have changed distro in the meantime, now I am running GNOME on Antergos. No high memory usage or slow system performance detected while running Evolution. Sure it takes some resources but stays around 200 MB which is acceptable. I have tested reading some HTML heavy emails and the memory usage does not seem to be growing over time. 

Antegros has also more recent versions so might I guess the performance is better too. I also have suspicion that some bad/generic drivers I had on Ubuntu caused some performance fluctuations in general. 

Thanks for all your tips, I suggest we can close this bug.