Clearing a simple to/from/subject search on evolution takes several seconds of high CPU usage with IMAP folders.
Name : evolution (Packaged rocky9)
Version : 3.40.4
Release : 10.el9_5.1
Architecture : x86_64
Clearing a search takes several seconds with the client often crashing or sending messages of “Evolution is not responding”.
The server has about 1000 folders of which a user may have up to about 400 subscribed.
Is this typical behaviour. Are they any optimisations which should/could be configured.
Subscribing to fewer folders isn’t really an option.
Hi,
I’m sorry to say that, but your version is ancient. Unless you are able
to reproduce it with the current upstream version, which is 3.54.x
stable series at the moment, even the 3.56.0 will be released in
roughly two weeks from now, there is not much what could be done here
with it, in the upstream. Your distro supports that version, thus you
need to ask them for help. There is no man power to be able to support
all the released versions down to 2021-08-13, which is the date your
version had been released (yes, you are using three and half years old
software; that’s a lot of time, involving a lot of changes in the code,
not only in the project itself, but also in the dependency libraries).
By the way, how long the search clear takes depend son the folder size.
One of my largest folders has currently 248840 messages and running the
search takes more time than clearing it, both within two seconds or
less, subjectively measured. Also, make sure the “Search … in …”
reads as “Search … in Current Folder”. The other options involve more
work, more complicated searches.
Problem was reproduced with the flatpak 3.54 so this issue has been introduced sometime between 3.28.5-27.el8_10 and 3.40.4
While older versions of evolution in the case 3.28.5-27.el8_10 show a similar time to do a simple search on a simple string across all messages across 600 folders and about 600000 messages.
Search takes about 12 seconds.
The time to clear a search on the old version is nearly instantaneous.
Newer versions freeze and appear to take as long or longer as the initial search to display a simple imap folder. During this period the mail client often crashes or warnings appear saying the client is not responding.
From the debug logs it appears to be grinding through some form of search, it’s not imap or network based and the CPU load is very high.
Why would it be doing this? Listing the folder would be much faster.
It’s not clear from your text what the “in …” part of the “Search
… in …” above the message list is. I suppose the old and the new
versions do not match, aka each having there a different value.
I’m asking about the green area here: https://gnome.pages.gitlab.gnome.org/evolution/help/intro-main-window.html
there it says “… in Current Folder”.
You mentioned flatpak, you mean “reproduced in Evolution 3.54.something
under flatpak”, I suppose, though the sentence as such is kinda
confusing, because the second part suggests like you wanted to say the
3.54.something did not reproduce the problem.
Parameters of the search.
Show: All Messages
Search: Subject or Address contain (Simple text string)
in: Current Account
Search takes 15 seconds however clearing search is problematic on 3.40.4-9 and 3.54 taking approximately 32 seconds with a frozen mail client. Often it crashes or pops up warnings relation to “not responding”
The older versions 3.28.5 search takes 9 seconds with the same parameter clears almost instantly.
Search takes 15 seconds however clearing search is problematic on
3.40.4-9 and 3.54 taking approximately 32 seconds with a frozen mail
client.
Okay, I see, searching in the whole account, where you’ve 600 folders
and around 600K messages is a problem. The search folders code changed
between the two versions, which can explain the reason, though I’d not
expect that significant downgrade, especially with the search clear.
Often it crashes or pops up warnings relation to “not responding”
There’s a difference between a freeze and a crash. The warning about
“not responding” relates to an app freeze, which, most often, means the
main/UI thread is busy with something and blocks the even queue, which
the desktop environment evaluates as the app is not responding and asks
to kill it. The app can recover from this state once it finishes what
it had been doing in that thread. The crash is about the app
disappearing, usually with a backtrace, due to some problem, an error
in the code.
It would help to file a bug against the evolution-data-server, which
contains a libcamel code, where these things are located. The link for
it is here:
It’ll help to not be forgotten (I think it’s not filled yet, neither in
the eds nor in the evolution issues, but feel free to correct me).
Yes, however both behaviours appear and may of may not be related however given the fact that they’re occuring in close temporal proximity it suggests some they’re there could be causality.
I’ve run evolution using the following command
CAMEL_DEBUG=all evolution >& logfile-1.txt
clearing the search from this point on produces a logfile
===========
DB SQL operation [SELECT value FROM ‘folders’ WHERE id=‘folder://7d4aab709d908d7e68f8edd98fa4683b7379dffe/INBOX’ AND key=‘autoarchive’] started
Camel SQL Exec:
SELECT value FROM ‘folders’ WHERE id=‘folder://7d4aab709d908d7e68f8edd98fa4683b7379dffe/INBOX’ AND key=‘autoarchive’
DB Operation ended. Time Taken : 0.000141
###########
0x5563f45d9170: 0 0 0 | 4091 537772 537865
0x5563f45d9170: 0 0 0 | 4091 537771 537864
0x5563f45d9170: 0 0 0 | 4091 537771 537864
0x5563f45d9170: 0 0 0 | 4091 537770 537863
… Repeats > 1M times
0x5563f45d9170: 0 0 0 | 0 2 2
0x5563f45d9170: 0 0 0 | 0 2 2
0x5563f45d9170: 0 0 0 | 0 1 1
0x5563f45d9170: 0 0 0 | 0 1 1
0x5563f45d9170: 0 0 0 | 0 0 0
[imapx:A] adding command, format = ‘IDLE’
[imapx:A] completing command buffer is [4] ‘IDLE’
[imapx:A] completing command buffer is [0] ‘’
[imapx:A] camel_imapx_server_process_command_sync: (nil) () ~> 0x5563f49eb6a0 (IDLE)
This is using evolution packaged with rocky9
evolution-3.40.4-10.el9_5.1.x86_64
The ‘all’ log is usually not useful, because it longs really
everything. Finding relevant bits out of it is usually problematic.
I won’t try to decipher it, targeted debugging is better.
Having not filed an issue report previously, do I need to create
another account to log into this system to create an issue report?
Hmm, I do not know whether GNOME shares users between discourse and
GitLab, probably not. If it would be a problem just let me know and
I’ll fill the bug for you.