Opened 10 years ago

Closed 10 years ago

Last modified 10 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 10 years ago.
Shark Trace right after starting the application
Transmission_Shark_r9934_Running (55.9 KB) - added by exiva 10 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 10 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 10 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 10 years ago by exiva

Shark Trace right after starting the application

Changed 10 years ago by exiva

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

comment:3 in reply to: ↑ 2 Changed 10 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 10 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 10 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 10 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 10 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 10 years ago by livings124

r9947, that is

comment:9 Changed 10 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 10 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 10 years ago by jortuny

Yep, it seems fine now.

Note: See TracTickets for help on using tickets.