GNOME Bugzilla – Bug 333113
problem fetching summary information for new messages
Last modified: 2006-05-26 12:50:56 UTC
Please describe the problem: fetch of summary information for new messages is slow and prevents using inbox while running (inbox messages' screen is empty with white background on it). exchange server is w2003 sp1 with exchange 2003 sp1. my inbox on exchange is about 3500 messages and 166MB of size Steps to reproduce: 1. open evolution and synchronize so that no new messages 2. close evolution 3. re-open evolution immediately Actual results: after step 3 it takes again about 2 minutes to have phase named "fetching of summary information for new messages" (in bottom bar) completed. In the mean time I see no messages in inbox available to work with and I cannot work Expected results: initial fetch phase going in background letting me able to open my previous e-mails and work with them in the mean time. Does this happen every time? yes Other information: using rawhide with these versions: evolution-sharp-0.10.2-8 evolution-webcal-2.4.1-3.2 evolution-2.5.92-1 evolution-connector-2.5.92-1 evolution-data-server-1.5.92-1
I'm seeing the same issues too with an Exchange 2003 SP2 server. Its a remote server so the constant updating makes it _REALLY_ slow.
Fedora Core 5 and with evolution-2.5.92-1 eats my CPU. I did some restarts, evolution does not fetching, not pop communication, nothing, just eating .. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 16324 rvokal 16 0 395m 79m 19m S 98 7.9 11:14.37 evolution Might be also a problem with new dbus-0.60-7 Some more info I can provide?
Gianluca Cecchi, Your server is also a remote server? Peter, Gianluca: We are not seeing this issue with our server (in LAN) See http://go-evolution.org/StressEvoConnector and also comment #3 in the bug #320067. How is the performance with OWA (browser) ? can you set E2K_DEBUG=4 and run evolution-exchange-storage from console and see if it waits on any response? also attach gdb to evolution-exchange-stroage process and run the command "thread apply all bt" when it seems to do nothing. see http://live.gnome.org/GettingTraces or more details. Radek Vokal, This type of memory hog is also not seen by us. Lots of leaks are fixed in 2.5.92 See bug #329251. Can you attach gdb to evolution-exchange-storage and get the traces as explained above and get the traces when you see the memory buildup? also your problem looks different than this bug report. so it is better to file a new bug.
MArking as needinfo
my server is in the same lan of the fc5 client and I configured this account giving its ip address on the lan (that is a Gbit lan). my system is x86_64 i read about bug 320067. my complete mailbox size is 590MB with about 13000 items, distributed in 47 folders. The inbox has 3538 items and 110MB. Yesterday evening I closed evo and when I open evolution this morning I wait: 20 seconds for "scanning for changed messages" from 0% to 100% 70 seconds for "fetching summary information..." where it remains at 0% 20 seconds after it begins to move, to pass from 1% to 100% Take in mind that at the end there are 18 new messages after operation completed. After that, if I close and reopen evolution, I get 5 seconds for the scan phase 10 seconds for the fetch, to be operational. So it seems the problem is also relative to first start... BTW, when I see the "fetching information...." in the bottom bar, it would be nice to see for which folder the activity is going on. At the moment I see only many of these operations, that I presume are folder by folder (in my case 47 times) Performance with owa browser is pretty ok with firefox. Running evolution-exchange-storage (that is not in my PATH so I have to run with complete path) gives nothing at all on screen with the debug 4. Would I have to see any message? Attaching gdb from another console I see:
+ Trace 66647
Do I have to start both this command and evolution or what? Also reading the getting trace page I have not quite understood how to apply in my case with your requests... sorry Gianluca
(In reply to comment #3) > Radek Vokal, > This type of memory hog is also not seen by us. > Lots of leaks are fixed in 2.5.92 > See bug #329251. > Can you attach gdb to evolution-exchange-storage and get the traces > as explained above and get the traces when you see the memory buildup? > also your problem looks different than this bug report. > so it is better to file a new bug. Seems like I have a problem with the latest dbus, the console is spammed with libnm_glib_dbus_init: error, org.freedesktop.DBus.Error.NoServer raised: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused
It never use to be this slow in previous releases of evolution (2.2 and I think 2.4). My inbox is around 200Mb in size consisting of around 4300 messages. It just seems to rescan every message everytime I run evo, although the later releases have been considerably more stable than the earlier versions of 2.5 which is nice.
There are a lot of bugs opened for performance. If performance is the problem then I hope this bug can be cloased and we can use #341214 for tracking performance related issues. If anyone still facing problem in fetching mails, please reopen.