Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#2759 closed Bug (fixed)

Excessive CPU Usage

Reported by: exiva Owned by: livings124
Priority: High Milestone:
Component: Transmission Version: 1.76+
Severity: Major Keywords:
Cc:

Description

r9929 seems to be using an excess of CPU. Much much more than 1.76 uses. Almost a steady 70-100% I actually think this might be related to the fix for #2416

I'll do some testing and reply to this with what I find.

Attachments (2)

Transmission_Shark_r9934_Boot (63.2 KB) - added by exiva 9 years ago.
Shark Trace right after starting the application
Transmission_Shark_r9934_Running (55.9 KB) - added by exiva 9 years ago.
Shark Trace after the app has been running for a few minutes

Download all attachments as: .zip

Change History (13)

comment:1 Changed 9 years ago by exiva

for comparison, r9837 uses about 30-35% CPU. (The earliest version I have on my computer.) The last build I have before the fix was implemented for #2416 uses about is r9899 and the same 30-35% cpu before it crashes. However, in r9929 it's a constant 70-100%

comment:2 follow-up: Changed 9 years ago by livings124

  • Component changed from Mac Client to Transmission

Could you do a shark trace (http://trac.transmissionbt.com/wiki/Shark) and report back.

Changed 9 years ago by exiva

Shark Trace right after starting the application

Changed 9 years ago by exiva

Shark Trace after the app has been running for a few minutes

comment:3 in reply to: ↑ 2 Changed 9 years ago by exiva

Replying to livings124:

Could you do a shark trace (http://trac.transmissionbt.com/wiki/Shark) and report back.

Added two shark traces.

comment:4 follow-up: Changed 9 years ago by charles

Thanks exiva. I'm not positive, but it seems to me that those shark traces agree with you, that the #2416 workaround of having libevent use poll() rather than kqueue() uses more CPU. The libevent developers are working on a fix for their kqueue() code, but it's an open question whether it will be done in time for 1.80...

What version of OS X are you using?

comment:5 in reply to: ↑ 4 Changed 9 years ago by exiva

Replying to charles:

Thanks exiva. I'm not positive, but it seems to me that those shark traces agree with you, that the #2416 workaround of having libevent use poll() rather than kqueue() uses more CPU. The libevent developers are working on a fix for their kqueue() code, but it's an open question whether it will be done in time for 1.80...

What version of OS X are you using?

I'm running 10.6.2 with all the latest updates.

comment:6 Changed 9 years ago by jortuny

I can definitely confirm this bug, and my shark trace looks pretty similar. Happened right after the switch to poll(). With many torrents open transmission now pegs one core at 100% which is fairly annoying.

comment:7 Changed 9 years ago by livings124

r9946 is using the kqueue backend again. exiva and jortuny, please update, test, and report back, whether it's good news or bad news.

comment:8 Changed 9 years ago by livings124

r9947, that is

comment:9 Changed 9 years ago by jortuny

I ended up removing a vast majority of the torrents I was on because of the CPU usage :-(. But I'll download and test anyways since even with only a few when seeding it pegs the CPU and see what happens.

comment:10 Changed 9 years ago by livings124

  • Milestone None Set deleted
  • Resolution set to fixed
  • Status changed from new to closed

In my own tests I have confirmed the switch back to kqueue has resolved this issue. Please reopen if this is not the case with a current nightly build.

comment:11 Changed 9 years ago by jortuny

Yep, it seems fine now.

Note: See TracTickets for help on using tickets.