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 631582 - evolution extremely slow and resource hungry at times
evolution extremely slow and resource hungry at times
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: BugBuddyBugs
2.32.x (obsolete)
Other Linux
: Normal blocker
: ---
Assigned To: Evolution Triage Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2010-10-07 05:57 UTC by Ruchir Brahmbhatt
Modified: 2011-02-14 17:07 UTC
See Also:
GNOME target: 3.0
GNOME version: ---


Attachments
strace (721.70 KB, application/x-bzip)
2011-01-13 12:53 UTC, Ruchir Brahmbhatt
Details

Description Ruchir Brahmbhatt 2010-10-07 05:57:59 UTC
OS: opensuse 11.3 x86_64
Evolution: 2.32.0
Account: Gmail IMAP+
Calendar: Gmail

Evolution consumes lots of resources and makes whole system quite slow. Many times it uses lot of cpu and RAM specially when it shows status "Storing folder". This storing folder operation seems quite slow and takes longer. I have 4G RAM but when I use evolution, free memory goes down to ~30M. When I close it, it comes up to 1.3G. So as per that it seems evolution uses >1G memory(25% of total) which I think it not normal.
Comment 1 André Klapper 2010-10-07 09:33:04 UTC
Can you provide valgrind / strace info?
Currently the report is a bit vague...
Comment 2 Ruchir Brahmbhatt 2010-10-07 10:32:03 UTC
Can you please guide how to get it.
Comment 3 Ruchir Brahmbhatt 2010-10-08 13:56:14 UTC
Does it have any relation with sent mail folder which is ~1.5G? As it consumes memory around that size and "Storing folder" message is probably for sent folder but not 100% sure though.
Comment 4 Akhil Laddha 2010-11-18 04:28:29 UTC
When you see high cpu load, please get gdb traces. To achieve this, start evolution under gdb, when cpu goes high like 85-100%, do 'ctrl+c', then 't a a bt' and paste the traces here. 

If you are seeing high memory consumption, then use valgrind. Please refer https://wiki.ubuntu.com/Valgrind for more information.

If possible, please upgrade to Evolution 2.32.1.
Comment 5 Fabio Durán Verdugo 2011-01-03 02:06:44 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!
Comment 6 Ruchir Brahmbhatt 2011-01-13 11:52:29 UTC
This still persists in 2.32.1. Below are gdb traces as requested. I'll send valgrind info later.


^C
Program received signal SIGINT, Interrupt.
0x00007ffff5e5b6b3 in poll () from /lib64/libc.so.6
(gdb) t a a bt

Thread 34 (Thread 0x7fffdd38c710 (LWP 24339))

  • #0 read
    from /lib64/libpthread.so.0
  • #1 ??
    from /usr/lib64/libcamel-1.2.so.19
  • #2 ??
    from /usr/lib64/libcamel-1.2.so.19
  • #3 ??
    from /usr/lib64/libcamel-1.2.so.19
  • #4 camel_mime_parser_step
    from /usr/lib64/libcamel-1.2.so.19
  • #5 camel_mbox_summary_sync_mbox
    at camel-mbox-summary.c line 1194
  • #6 mbox_summary_sync_full
    at camel-mbox-summary.c line 705
  • #7 mbox_summary_sync
    at camel-mbox-summary.c line 1021
  • #8 local_sync
    at camel-local-folder.c line 524
  • #9 camel_folder_sync
    from /usr/lib64/libcamel-provider-1.2.so.19
  • #10 mail_msg_proxy
    at mail-mt.c line 469
  • #11 g_thread_pool_thread_proxy
    at gthreadpool.c line 319
  • #12 g_thread_create_proxy
    at gthread.c line 1897
  • #13 start_thread
    from /lib64/libpthread.so.0
  • #14 clone
    from /lib64/libc.so.6
  • #15 ??

Comment 7 Ruchir Brahmbhatt 2011-01-13 12:23:06 UTC
Valgrind log was bigger hence uploaded at below location.

http://www.filefactory.com/file/b4hbg5b/n/valgrind.log.tar.bz
Comment 8 Ruchir Brahmbhatt 2011-01-13 12:53:14 UTC
Created attachment 178219 [details]
strace

This is the strace from start to condition of more memory usage(~2% of 4GB) and sluggishness. 
Free memory before starting evo: ~1G
Free during execution: ~35M
Free memory on closing evo: ~1G

I feel it is partly due to sent mails size.
Size of Sent mail: 1.6G
Comment 9 Ruchir Brahmbhatt 2011-01-22 05:17:01 UTC
I think this should be taken as higher priority as it is happening often during the day and every time I send new email. Evolution makes my whole system slow, leaves barely 30M free memory and hence I can't use other apps also and have to wait for evolution to finish current operation.
Comment 10 Ruchir Brahmbhatt 2011-02-02 11:36:39 UTC
I recently created a maildir account and configured my primary account to use "Sent Mail" of that new maildir account for sent emails and it is working much better now. I think 2.91.x branch has maildir option for sent mails but I don't have packages in suse repo to try so I'll check later and accordingly close the issue.
Comment 11 Milan Crha 2011-02-14 09:36:36 UTC
(In reply to comment #10)
> I think 2.91.x branch has maildir option for sent mails but I don't
> have packages in suse repo to try so I'll check later and accordingly close
> the issue.

That's true, 2.91.5+ or such uses maildir as a local mail storage, which doesn't have one file per folder, but one file per message, which makes all this kind of stuff behave much better than with mbox format.
Comment 12 Ruchir Brahmbhatt 2011-02-14 09:41:03 UTC
Yeah I noticed that when I switched to 2.91.5 yesterday as it migrates mbox to maildir. Although I had to switch back to 2.32.1 because of other issues with message list display, we can consider this bug fixed so marking status as such.
Comment 13 Milan Crha 2011-02-14 09:51:20 UTC
Thanks. Use rather recent version, which is 2.91.6, though the git master is the best bet these days, due to fixes on gtk3 side as well.
Comment 14 Milan Crha 2011-02-14 17:07:22 UTC
I tried to reporduce it here anyway, and apart of some slowness which is sort of expected when doing expunge of 1.5GB file I didn't find much. I fixed few leaks, though.