Red Hat Bugzilla – Bug 139145
Evolution 2.0.2 very slow when using IMAP
Last modified: 2007-11-30 17:10:54 EST
Description of problem: I run Evolution 2.0.2 to connect to an IMAP mail server. I have approximately 290 messages in my inbox (many mailing lists and some archived mail). I notice that when I change to another mail folder and then back to my inbox it seems that Evolution takes a long while - sometimes 15-20 seconds or more - to display. The mail server is on the same LAN, connected via 100 megabit ethernet. There are only two users accessing the mail server when this happens. I also notice that when Evolution 2.0.2 appears hung, the drive light on the mail server are on solid the entire time - it's like Evolution is somehow re-downloading all headers every time I access a folder. This does not happen on an older Linux workstation I have which is running Evolution 1.4. Version-Release number of selected component (if applicable): Evolution 2.0.2 How reproducible: 1. Configure Evolution to use IMAP to get mail 2. Login to mail server 3. Open mail folder with three hundred messages Steps to Reproduce: 1. Configure Evolution to use IMAP to get mail 2. Login to mail server 3. Open mail folder with several hundred messages Actual results: Slow response and steady disk activity on the mail server every time the mail folder is checked. Expected results: Response as fast as Evolution 1.4 (nearly instant). Additional info: I am not sure what additional info I can or should provide. The system I am working on is a Compaq Proliant ML350 with dual 2.8GHz Xeon processors, 2GB memory and 15,000RPM Ultra320 SCSI drives hanging off a SmartArray RAID controller. The machine is pretty snappy, so I don't think it's the issue.
Wild guess but you haven't told evolution to sync all mails each time have you? Tools -> Settings... Mail Accounts -> (Edit your IMAP account) -> Receiving Options -> Automatically synchronise remote mail locally
No, this is not the case, sorry. That checkbox is clear, not checked.
Please can you run evolution with the environment variable CAMEL_VERBOSE_DEBUG=1 This should make Evolution write out the full IMAP conversation it's having with the server to stdout. This should give us more information on what's going wrong. Thanks.
Created attachment 106879 [details] Log of starting and immediately exiting Evolution.
Sorry, my comments from my previous post did not make it when I uploaded the file. This log is from me starting Evolution and then exiting as soon as the folder list is displayed. Time to start was well over a minute. Interestingly, I went through a mailbox with ~200 messages in it and displayed each one to see if I could get it to do that random pause but it would not appear.
This is when I clicked on the "Drafts" folder which is empty, then clicked on "Inbox" which has 335 messages in it. It took almost a minute before the "Refreshing Folder (...)" message at the bottom of the Evolution screen went away. sending : A00570 SELECT Drafts received: * 0 EXISTS received: * 0 RECENT received: * OK [UIDVALIDITY 1026884229] UID validity status received: * OK [UIDNEXT 26] Predicted next UID received: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) received: * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags received: A00570 OK [READ-WRITE] SELECT completed sending : A00571 SELECT INBOX received: * 335 EXISTS received: * 0 RECENT received: * OK [UIDVALIDITY 1081433329] UID validity status received: * OK [UIDNEXT 3494] Predicted next UID received: * FLAGS ($MDNSent Junk NonJunk \Answered \Flagged \Deleted \Draft \Seen) received: * OK [PERMANENTFLAGS ($MDNSent Junk NonJunk \* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags received: * OK [UNSEEN 41] first unseen message in /var/spool/mail/thomas.cameron received: A00571 OK [READ-WRITE] SELECT completed sending : A00572 FETCH 335 UID received: * 335 FETCH (UID 3493) received: A00572 OK FETCH completed
I too also have the same issue however I have notice on each pause between folder changes evolution produces the following output. ** (evolution:9052): CRITICAL **: file atktable.c: line 151 (atk_table_ref_at): assertion `row >= 0' failed ** (evolution:9052): CRITICAL **: file atktable.c: line 151 (atk_table_ref_at): assertion `row >= 0' failed
Re comment #7: this looks like you've found a bug in Evolution's accessibility code. Thomas Cameron: do you see these messages? I don't see any in the log you attached. Do you have accessibility turned on, BTW? (run desktop Main Menu->Preferences->Accessibility->Assisitive Technology Support, see if "Enable Assistive Technologies" is on) My guess at the moment is that comment #7 is a separate bug, but there's a chance that it might be what the problem is here. Evolution does run noticeably slower for me when I turn accessibility on.
I do not see these messages, and I do not have accessibility turned on. I concur that comment #7 is a separate bug.
BTW - I am planning on moving mail to a newer server running Courier instead of Wash U IMAP over this weekend. I understand that Courier is much faster, so hopefully that will resolve/mask the issue.
Note: I see this too on 2.0.2 on a Debian unstable system. I filed this upstream: http://bugzilla.ximian.com/show_bug.cgi?id=69686 Let's hope we can track it down! /Mikael
Yes I did have the accessibility stuff turned on, and switching it off fixed the speed problem, should I go open a new bug ? Or has somone already done so.
Further to comment #10, I don't think the problem lies in Washington's imapd vs Courier. We run Washington's imapd on a Sun Solaris 9 server and connecting to my account on it with Evolution takes many minutes, yet using Thunderbird 0.9, it's almost instantaneous. I like Evolution and used to use it for tasks/calendar as well as mail but switched to Thunderbird for mail and Sunbird for tasks/calendar because Evolution is unfortunately so slow as to be unusable in our setting.
The change from wu to courier fixed it for me. BUT I also upgraded the mail server from a P3 800MHz with 256MB memory and IDE drive to a dual Xeon 2.8GHz machine with 15,000RPM Ultra320 drives on a caching RAID controller and 2GB memory. So it might be that the mail server is just so much faster that Evo's bad behavior is being masked.
The IMAP code has been thoroughly rewritten for Evolution 2.2 - this is available in Rawhide. Is anyone trying the new code, and if so, are you seeing the slowness?
I have the same problem and I confirm comment 13: the problem does not depend on the imap server as evolution 1.4 was working just fine with the same server I am using now. I would add that it does not depend on imap neither as I notice the same slow behaviour on all the local folders with imap account disabled. Could it be that the problem is related to the fact that my home directory is NFS mounted ? As far as I understand evolution 2 stores files differently from version 1.4. It seems that it's even using bdb to store folders... if that's true then I think it is a bad mistake as everybody knows that bdb has problem with nfs due to sync problems.
I have now tried 2.2.1.1 in Debian. First, I switched to the new IMAP4rev1 server type. The problems persist, but the new code bahaves differently in some cases. The net result is anyway that Send/Receive takes 10 minutes ("Scanning folders...") and setting mail check interval to 10 mins makes evo unusable, as it rescans and rescans.... Meanwhile my wu imapd server is working like a dog. Changing servers and moving to maildir is a workaround, but the bug is in evolution. I do not use NFS, so that can probably be ruled out. Maybe someone could update the summary to reflect the 2.2.1.1 problems too. ===> I need to switch to thunderbird. /Mikael
Upstream bugzilla has moved. New upstream bug location: http://bugzilla.gnome.org/show_bug.cgi?id=269686 /Mikael
I have finally gotten Evolution 2.2 installed. I see a fair increase in performance. It seems to be about the same speed as T-bird now. Very nice!
OK, I spoke too soon. It is real hit-or-miss. Sometimes it runs quickly, but other times it seems to re-scan the entire IMAP folder randomly, locking up Evo for up to a minute for a big folder. Startup time is better, though.
Quote from fejj in upstream bugzilla: "anyways, yes, it does turn out that IMAP4rev1 code is slower than the old IMAP code in this respect - my suggestion: don't use IMAP4rev1 (likely it's going away anyway since I'm no longer working on it and have left the evolution team)" http://bugzilla.gnome.org/show_bug.cgi?id=269686 :-/ At approx the same time, the bug was marked "Major" and Target set to 2.3. So we might get this bug fixed in the next devel cycle of evolution... /Mikael
Is anyone using the "IMAP4rev1" backend? (I'm thinking of disabling this from the package builds; it appears to have been abandoned by upstream)
After changing to dovecot as imap server, I can now use the regular IMAP backend without issues, so no IMAP4rev1 for me any longer...
I have abandoned Evolution for Thunderbird. Also, this version of Evolution is pretty much dead and buried I think. I suggest closing this BZ.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!