Closed Bug 1918905 Opened 2 months ago Closed 1 month ago

100%+ cpu on linux; have lots of idle test accounts; seems cause is continuous/indeterminate progress bar movement

Categories

(Thunderbird :: Mail Window Front End, defect)

Thunderbird 128
Unspecified
Linux
defect

Tracking

(thunderbird_esr128 unaffected)

RESOLVED INVALID
Tracking Status
thunderbird_esr128 --- unaffected

People

(Reporter: gds, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: perf, Whiteboard: [has performance profile])

I've been seeing high cpu and quick bettery drain for a while with test profile (lot of imap, several pop3 and a few nntp accounts) all mostly just idle with little or no network activity going on, even at startup (check for new msgs at startup and biff disabled on all accounts). With self-built trunk with debug, I see well over 100% continuous cpu activity on TB in "top". With downloaded daily from today (optimized) I see 80-90% continuous cpu activity, so optimization helps. The high cpu seems to correlate to continuous status bar movement (shown as indeterminate pulsing). If I turn off the status bar in "view" menu the cpu activity falls to almost nothing with and without optimization. So it seems the excess cpu is caused by the status bar continuously attempting to update with progress indeterminate.
Here's a link to a profile I recorded for about 14 seconds. I'm not an expert at understanding it; most of the activity seems be in areas I'm not familiar with.
https://share.firefox.dev/3B1PN17

Blocks: 1918961
Keywords: perf
Whiteboard: [has performance profile]
Summary: 100%+ cpu on linux; have lots of idle test profiles; seems cause is continuous/indeterminate progress bar movement → 100%+ cpu on linux; have lots of idle test accounts; seems cause is continuous/indeterminate progress bar movement

Gene, are you hitting this only on version 132 or have you hit it on other versions?

I made a try build on top of 128.2.2esr with a very minor patch (this was for another bug) and I see it when running that too (status progress bargraph continuously pulsing). Again, if I disable the status bar the cpu usage drops back to normal. So it seems to be independent of version.
Also, I only see it with one profile that has a lot of random and usually inactive accounts that I've setup over several years, most for testing TB.

Can you do the same with 128.2.3? I wonder if this is related to the OAuth patches we backed out. They're still on central.

Flags: needinfo?(gds)

(In reply to Geoff Lankow (:darktrojan) from comment #3)

Can you do the same with 128.2.3? I wonder if this is related to the OAuth patches we backed out. They're still on central.

Still see it with 128.2.3 (downloaded from archives). I only have one account active on network and it is not oauth, just tls/plain pwd. I do have other accounts, some oauth, but they are essentially disabled network wise (no check for messages at startup, no check every X minutes).

With 128.2.3 and status bar turned on I'm seeing TB always at the top with "top". CPU usage shows between 60 and 90%, usually closer to 70. Status bar continuously moving.
With status bar turned off, TB CPU usage in "top" is barely registering.

Flags: needinfo?(gds)
Version: Trunk → Thunderbird 128

Gene, would you be able to look into fixing this?

Flags: needinfo?(gds)

Was meaning to look at this for a few days when I noticed there was a bar graph in "Activity Manager" going crazy (moving back and forth). It mentioned a message name, the subject I assume. I searched folders for the name and finally found it in Local Folders/Outbox. Apparently while working on bug involving "Send Later" a message got left in outbox and couldn't send (just a test message so nothing important). I deleted the contents of LF/Outbox and it removed the bar graph in Act Mgr and now I can again show status bar without TB going to 100+% cpu.
So I'm closing this as invalid.

Status: NEW → RESOLVED
Closed: 1 month ago
Flags: needinfo?(gds)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.