GNOME Bugzilla – Bug 583182
Evolution is constant storing folders which takes up to much of my I/O
Last modified: 2011-07-29 15:37:48 UTC
Please describe the problem: It seems my evolution need to constantly re-store my folders, which is becoming a huge problem for my productivity. It takes up so much I/O that even browser operations becomes a pain, but also makes it nearly impossible to use it for everyday mail and calender needs. I suppose this is only a problem since I have a huge mailbox, but I require my mails stored locally in my folders and as many as possible. Steps to reproduce: 1. Large amount of mails, and many folders (I have 56) $ du -sh .evolution/ 4.6G .evolution/ 2. Have an active mailbox, filtering new mails to multiple Folders. 3. Close and Start-up evolution will cause it to take up large amount of resources and for a very long time, while re-storing folders. Actual results: Evolution uses large amount of resources and makes it impossible to use it as mail or calender client. Not suitable for work. Expected results: Evolution uses large amount of resources and makes it impossible to use it as mail or calender client. Not suitable for work. Does this happen every time? Yes, several times a day while using it. Other information:
One min worth of pidstat data, 10:18:59 PID kB_rd/s kB_wr/s kB_ccwr/s Command 10:19:00 17678 360.00 1476.00 0.00 evolution 10:19:01 17678 360.00 1412.00 0.00 evolution 10:19:02 17678 416.00 400.00 0.00 evolution 10:19:03 17678 36.00 196.00 0.00 evolution 10:19:04 17678 36.00 140.00 0.00 evolution 10:19:05 17678 24.00 160.00 0.00 evolution 10:19:06 17678 44.00 240.00 0.00 evolution 10:19:07 17678 44.00 132.00 0.00 evolution 10:19:08 17678 40.00 156.00 0.00 evolution 10:19:10 17678 348.00 1512.00 0.00 evolution 10:19:11 17678 396.00 956.00 0.00 evolution 10:19:12 17678 400.00 1464.00 0.00 evolution 10:19:13 17678 436.00 1172.00 0.00 evolution 10:19:14 17678 44.00 280.00 0.00 evolution 10:19:15 17678 44.00 100.00 0.00 evolution 10:19:16 17678 31.68 126.73 0.00 evolution 10:19:17 17678 36.00 116.00 0.00 evolution 10:19:18 17678 88.00 152.00 0.00 evolution 10:19:19 17678 80.00 60.00 0.00 evolution 10:19:20 17678 368.00 1468.00 0.00 evolution 10:19:21 17678 392.00 1188.00 0.00 evolution 10:19:22 17678 431.68 1271.29 0.00 evolution 10:19:23 17678 360.00 892.00 0.00 evolution 10:19:24 17678 32.00 276.00 0.00 evolution 10:19:25 17678 32.00 260.00 0.00 evolution 10:19:26 17678 40.00 248.00 0.00 evolution 10:19:27 17678 48.00 204.00 0.00 evolution 10:19:28 17678 40.00 144.00 0.00 evolution 10:19:30 17678 92.00 280.00 0.00 evolution 10:19:31 17678 372.00 1256.00 0.00 evolution 10:19:32 17678 388.00 456.00 0.00 evolution 10:19:33 17678 424.00 1772.00 0.00 evolution 10:19:34 17678 352.48 1409.90 0.00 evolution 10:19:35 17678 12.00 16.00 0.00 evolution 10:19:36 17678 40.00 40.00 0.00 evolution 10:19:37 17678 48.00 40.00 0.00 evolution 10:19:38 17678 44.00 36.00 0.00 evolution 10:19:39 17678 44.00 84.00 0.00 evolution 10:19:40 17678 48.00 400.00 0.00 evolution 10:19:41 17678 132.00 812.00 0.00 evolution 10:19:42 17678 432.00 620.00 0.00 evolution 10:19:43 17678 364.00 1428.00 0.00 evolution 10:19:44 17678 356.44 1366.34 0.00 evolution 10:19:45 17678 144.00 128.00 0.00 evolution 10:19:46 17678 20.00 4.00 0.00 evolution 10:19:47 17678 12.00 12.00 0.00 evolution 10:19:48 17678 32.00 24.00 0.00 evolution 10:19:49 17678 76.00 616.00 0.00 evolution 10:19:50 17678 392.00 1020.00 0.00 evolution 10:19:51 17678 448.00 1548.00 0.00 evolution 10:19:52 17678 412.00 912.00 0.00 evolution 10:19:53 17678 376.00 1724.00 0.00 evolution 10:19:54 17678 348.00 772.00 0.00 evolution 10:19:55 17678 24.00 164.00 0.00 evolution 10:19:56 17678 32.00 336.00 0.00 evolution 10:19:57 17678 28.00 164.00 0.00 evolution 10:19:58 17678 20.00 88.00 0.00 evolution 10:19:59 17678 8.00 48.00 0.00 evolution
I have only 76M of data in my ~/.evolution folder and I have exatcly the same problem. Does anyone is in charge of this issue?
I guess this had been addressed in bug #590044 , as I do not see such behaviour after fix applied from there. If anyone of you can try with it it'll be great. You can achieve quite similar behaviour, though not the same, by running the below script. It'll drop the offending index and replaces it with much smaller. #!/bin/sh cd ~/.evolution/mail/ for i in `find . -name folders.db` do echo "Altering Table $i" for j in `sqlite3 "$i" "SELECT folder_name FROM folders;"` do sqlite3 "$i" "DROP INDEX IF EXISTS \"SINDEX-$j\";" sqlite3 "$i" "CREATE INDEX \"SINDEX-$j\" ON '$j' (uid);" done sqlite3 "$i" "vacuum;" done
I am having this same issue after upgrading to 2.26.3 from Mandriva. I ran this script and received the following results, but it did not correct the problem: Altering Table ./local/folders.db SQL error: no such table: main.Archive/Rebecca SQL error: no such table: main.Lamping SQL error: no such table: main.Inbox/eBill SQL error: no such table: main.Pay SQL error: no such table: main.Inbox.ev-summary.old SQL error: table .#evolution/Junk has no column named uid SQL error: table .#evolution/Trash has no column named uid Altering Table ./vfolder/folders.db Altering Table ./pop/cjohnson@bce-inc.com@mail.bce-inc.com/folders.db I hope this helps. I really like evolution and need it to start working again.
Then probably some other issue. Or those "no such table" errors are related to it.
Thanks for taking the time to report this bug. However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use. Please try with an upcoming Evolution 2.30.0+, which is the one developers are working on now. Thanks.
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!
I am using Evolution version 2.32.2 and it has the problem described in the title line of this email, but even worse than in the description. It seems that no matter what I do in Evolution, it stops to store folders. If it fetches email, it stores folders; if I switch from viewing one folder to another, it stores folders; if I switch from viewing one email to another, it stores folders; if I move messages from one folder to another, it stores folders. And it takes a LONG time to store these folders--often minutes. This didn't used to be an issue with Evolution, even with large folders and many subfolders, but in 2.32.2 it's become a significant problem. It might help if I at least knew a specific circumstance that was causing it. Then I could try to avoid the folder-storing events until just before walking away for a while. But as far as I can tell, the these newer versions of Evolution just like to store folders a lot, with no particular prompting. If this is not the right place to report this, (e.g., if I should open up a new bug) then let me know, but the general complaint this bug describes seems to have been pushed into hyperdrive since version 2.32.
Did you try things described in comment #3, please? Alternatively, you can remove all folders.db files and indexes [1] and let evolution recreate them the next start, though you may loose some information for locally stored messages/folders by removing the folders.db files (it's usually some metadata, not messages itself). [1] check for a removal of index and summary files as described here: http://live.gnome.org/Evolution/FAQ#Why_do_I_get_an_error_.22Summary_and_folder_mismatch.2C_even_after_a_sync.22.3F
I have removed index and summary files a number of times. (Painful because then it really takes forever to reconstitute things). I just tried the script. It gives a bunch of "no such table" errors. Here's the output: Altering Table ./local/folders.db Error: no such table: main.zzArchive/Adoption Error: no such table: main.- Error: no such table: main.Maxim Error: no such table: main.Business/Web Error: no such table: main.Host Error: no such table: main.xT� Error: no such table: main.C� Error: no such table: main.Work/Job Error: no such table: main.Search Error: no such table: main.Lists/Linux Error: no such table: main.Stuff Error: no such table: main.Lists/C Error: no such table: main.Programming Error: no such table: main.Lists/Linux Error: no such table: main.Newbies Error: no such table: main.Lists/Linux Error: no such table: main.Forums Error: no such table: main.Lists/Subversion Error: no such table: main.Dev Error: no such table: main.Semi-Junk/Linked Error: no such table: main.In Error: table .#evolution/Trash has no column named uid Error: table .#evolution/Junk has no column named uid Altering Table ./pop/soyple@gmail.com@pop.gmail.com/folders.db Altering Table ./pop/dan@engelrealm.org@mail.engelrealm.org/folders.db Altering Table ./pop/dan@sourceharvest.com@mail.sourceharvest.com/folders.db Altering Table ./vfolder/folders.db Error: no such table: main.Account Error: no such table: main.Search Error: table Alerts has no column named uid Error: table UNMATCHED has no column named uid Error: no such table: main.Mail Error: no such table: main.from Error: no such table: main.Terry Error: no such table: main.Engel Error: table Technical has no column named uid Error: no such table: main.Catholic Error: no such table: main.News Running the script again yields the same result. Is this expected?
I figured out the "no such table" errors, and how to fix them. Here's a modified script: #!/bin/sh cd ~/.evolution/mail/ for i in `find . -name folders.db` do echo "Altering Table $i" sqlite3 "$i" "SELECT folder_name FROM folders;" | ( while read j do sqlite3 "$i" "DROP INDEX IF EXISTS \"SINDEX-$j\";" sqlite3 "$i" "CREATE INDEX \"SINDEX-$j\" ON '$j' (uid);" done ) sqlite3 "$i" "vacuum;" done I'm trying this now to see if *really* re-indexing the folder tables helps.
Nope, it still seems to store folders all the time, which is annoying because it seems like half the time "generating message list" pends on this activity. Furthermore, it takes FOREVER. Storing a folder with no more than a few hundred emails usually takes tens of seconds!