TB with lightning unresponsive at startup, with high CPU usage and cache disabled
Categories
(Calendar :: General, defect)
Tracking
(Not tracked)
People
(Reporter: mozilla, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: perf, Whiteboard: [dupme])
Comment 1•14 years ago
|
||
Reporter | ||
Comment 2•14 years ago
|
||
Comment 3•14 years ago
|
||
Comment 4•14 years ago
|
||
Comment 5•14 years ago
|
||
Comment 6•14 years ago
|
||
Comment 7•14 years ago
|
||
Reporter | ||
Comment 8•14 years ago
|
||
Comment 9•14 years ago
|
||
Reporter | ||
Comment 10•14 years ago
|
||
Comment 11•13 years ago
|
||
Updated•13 years ago
|
Comment 12•13 years ago
|
||
Comment 13•13 years ago
|
||
Reporter | ||
Comment 14•13 years ago
|
||
Comment 15•13 years ago
|
||
Comment 16•13 years ago
|
||
Comment 17•12 years ago
|
||
Comment 18•12 years ago
|
||
Comment 19•12 years ago
|
||
Comment 20•11 years ago
|
||
Comment 21•9 years ago
|
||
Comment 22•8 years ago
|
||
Comment 23•8 years ago
|
||
Comment 24•8 years ago
|
||
Updated•7 years ago
|
Comment 25•6 years ago
|
||
Reporter | ||
Comment 26•5 years ago
|
||
I have a Thunderbird 60.9.0 running which currently has 1483 open file descriptors.
Reporter | ||
Comment 27•5 years ago
|
||
Sorry, comment 26 was about "Bug 1240722 - Thunderbird leaks file descriptors".
Now, about this one here: Yes, when starting up thunderbird, there is always a spike in CPU load, and calendar feels sluggish, although it no longer is quite as bad as it used to be.
However, periodically, at random intervals, CPU goes up and lightning feels sluggish (hah!), but it usually goes back to normal (responsive) within a minute or so. However, the main issue with lightning seems to be that heavy processing is performed within the main event loop, rather than in a separate thread, with the result that even a moderate CPU load has an immediate negative impact on UI responsiveness.
Comment 28•5 years ago
|
||
I'm on ubuntu 19.10, thunderbird 68.1.2. For several months now (including on ubuntu 19.04) the calendar and tasks have slowed thunderbird right down to a halt, sometimes unresponsive for many minutes. This can be when just opening the calendar window, changing the displayed month or some other selection process. CPU stays at 100% for that process.
My calendar and tasks are all local.
With lightning disabled all is well.
Comment 29•4 years ago
|
||
Gary, do you also still see this issue, with 68 or 78 ?
Comment 30•4 years ago
|
||
I'm now on ubuntu 20.04, Tbird 68.10. The cause of the delays on my system was that I had a large number of completed tasks. I use many repeating tasks (often weekly or even more frequent) to remind me to do things, and the completed ones accumulated over the years. I went through the whole lot purging completed tasks, and in many cases deleted the task completely and recreating it. I don't get any serious delays any more.
Comment 31•4 years ago
|
||
Wayne Mery: I no longer see this issue in 68. I'm on 68.12, but it hasn't been a problem for months now -- maybe not for a few years.
Comment 32•4 years ago
|
||
I'm now on ubuntu 20.04, Tbird 68.10. The cause of the delays on my system was that I had a large number of completed tasks. I use many repeating tasks (often weekly or even more frequent) to remind me to do things, and the completed ones accumulated over the years. I went through the whole lot purging completed tasks, and in many cases deleted the task completely and recreating it. I don't get any serious delays any more.
So this purging of cruft and recreation of repeating tasks with newer TB seemed to help in this instance and got me to thinking. How hard would it be to implement a feature akin to "Purge completed task(s) after X Days, Months, Years?"
If someone is already leveraging "Offline Support" (which I assume means caching), this probably doesn't help much. But for those who aren't, is TB just going out and reading a calendar whose cruft may stretch back years or even decades with tens of thousands of old completed events only to spend time churning through them to come to the same conclusion every time TB starts or syncs: yup, these are dead completed tasks, nothing to see here?
I suppose there also exists the crowd who wants to be able to reference some calendar event that happened 10 years ago.
Comment 33•4 years ago
|
||
(In reply to Arthur K. [He/Him/His] from comment #32)
I'm now on ubuntu 20.04, Tbird 68.10. The cause of the delays on my system was that I had a large number of completed tasks. I use many repeating tasks (often weekly or even more frequent) to remind me to do things, and the completed ones accumulated over the years. I went through the whole lot purging completed tasks, and in many cases deleted the task completely and recreating it. I don't get any serious delays any more.
So this purging of cruft and recreation of repeating tasks with newer TB seemed to help in this instance and got me to thinking. How hard would it be to implement a feature akin to "Purge completed task(s) after X Days, Months, Years?"
Is that really the solution?
How come TB can handle hundreds of folders and thousands of emails (15GB of data) but crawl under one network calendar of max 2Mo in size with 4000 thousands of items spanning over 10 years (same period the mailbox was used!)?
I think the over all calendar feature may need to be designed in a way it can scale as data increase before thinking how to automatically deleting end-users data... no?
If someone is already leveraging "Offline Support" (which I assume means caching), this probably doesn't help much. But for those who aren't, is TB just going out and reading a calendar whose cruft may stretch back years or even decades with tens of thousands of old completed events only to spend time churning through them to come to the same conclusion every time TB starts or syncs: yup, these are dead completed tasks, nothing to see here?
I suppose there also exists the crowd who wants to be able to reference some calendar event that happened 10 years ago.
Someone may want (or need for regulatory reason) keep that much amount of data or more in their calendar... it should be possible... certainly TB should be able to handle it smoothly...
Updated•2 years ago
|
Reporter | ||
Comment 35•2 years ago
|
||
(In reply to Wayne Mery (:wsmwk) from comment #34)
Alain,
Does this still reproduce for you?
High CPU usage at start is still an issue, although no longer as bad as it used to be.
Moreover, after several days of running thunderbird, it again gets very slow, and stays slow. Restarting it fixes the issue (i.e. still slow right after restart, but then goes back to normal after a minute or so).
Comment 36•2 years ago
|
||
(In reply to Alain Knaff from comment #35)
(In reply to Wayne Mery (:wsmwk) from comment #34)
Alain,
Does this still reproduce for you?High CPU usage at start is still an issue, although no longer as bad as it used to be.
Moreover, after several days of running thunderbird, it again gets very slow, and stays slow. Restarting it fixes the issue (i.e. still slow right after restart, but then goes back to normal after a minute or so).
What version are you running now?
Reporter | ||
Comment 37•2 years ago
|
||
(In reply to Arthur K. (he/him) from comment #36)
(In reply to Alain Knaff from comment #35)
(In reply to Wayne Mery (:wsmwk) from comment #34)
Alain,
Does this still reproduce for you?High CPU usage at start is still an issue, although no longer as bad as it used to be.
Moreover, after several days of running thunderbird, it again gets very slow, and stays slow. Restarting it fixes the issue (i.e. still slow right after restart, but then goes back to normal after a minute or so).
What version are you running now?
102.6.0
Description
•