Unusually high CPU usage in latest builds

[iyttahmimsyafu]

I have about 1700 seeding torrents in Transmission. Until recently it wasn't a problem since T wouldn't use more than 10% of a core (which I consider pretty good for the number of torrents it is running) but since I started using the nightlies T uses at least 100% of a core. I already tried the latest build and the problem is still there, and just to be sure I downloaded 1.61 from the "Download" page and this version does not have that problem.

[iyttahmimsyafu]

Transmission's 1.61 CPU usage

[iyttahmimsyafu]

Latest nightly's CPU usage

[livings124]

Can you run a shark profile and post the results here.

​http://trac.transmissionbt.com/wiki/Shark

[livings124]

And what version is the nightly?

[charles]

please generate the shark profiles in the way described here: ​http://trac.transmissionbt.com/wiki/Shark

thanks!

[iyttahmimsyafu]

I'm using rev. 8588 and here's the shark profile ​http://transmission.pastebin.com/f35bb79a7

[charles]

thanks for the fast reply. :)

Most of that report is spent in libevent or libcrypto. In fact "tr_" -- the prefix for all of the libtransmission functions -- doesn't appear at all. I'm not sure what to do with that.

Is the CPU spike consistently there in the r8588, and consistently absent in 1.61 (r8383)? If so, does the problem exist in ​r8485? (8383+8588)/2 -- 8485

[iyttahmimsyafu]

Yes the spike is consistent, r8588 uses all at the time 100%. I downloaded 8485 and the problem is there. At least we narrowed it down 100 revisions :P

[charles]

Well, at least the 100% spike should make it easier to figure out what's wrong. :/

If the spike you're seeing showed up sometime between r8383 and r8485, then give r8434 a try. (8383+8485)/2... well there's not a build for that, but there is one for ​r8430, which is close.

​http://transmission.xpjets.com/OLD/2009/05/ is place to find the other dmg files. Since Shark wasn't any help, if you've got the time it would be good if you could divide the revisions by 2 a couple more times.

Odd that I'm not seeing this spike.... you say you're just seeding?

[iyttahmimsyafu]

Yes just seeding , not even downloading.

OK, I'll try testing those old builds and I'll report back when I can't divide by 2 anymore or if I find a build that's not affected :P

[iyttahmimsyafu]

I divided by 2 and tried these revisions: r8485, r8430, r8406 and r8393. r8393 does not appear to be affected, CPU usage stays under 10%; so the problem must should be between r8394 and r8405

[iyttahmimsyafu]

I tested r8398, r3896 and r3895. And while r3898 and 3896 would not even respond and constantly use ~120% of my CPU, r3895 stayed at ~70% for a while and is now back at ~10%.

[livings124]

I assume you mean r8395, r8396, and r8398?

[iyttahmimsyafu]

oh yes :P two many numbers for me heh

[charles]

:)

[charles]

r8393: "does not appear to be affected, CPU usage stays under 10%"
r8495: "stayed at ~70% for a while and is now back at ~10%"
r8396: "would not even respond and constantly use ~120% of my CPU"

r8393: add --paused argument to daemon to pause all on startup
r8494: #2035: T causes wakeups by unnecessary poling
r8595: (trunk gtk) add a mnemonic for "use speed limit between" in prefs
r8596: kjg's patch for #2061

[charles]

bah, I got the revisions messed up too. those are all r83xx :)

[charles]

okay. so iyttahmimsyafu's says the problem showed up sometime in (r8393...r8396].

• r8393 is a change to the daemon; doesn't touch the mac client
• r8394 is a change to libtransmission; does affect the mac client
• r8395 is a change to the gtk client; doesn't touch the mac client
• r8396 is a change to the web client; doesn't touch the mac client

[charles]

Is the cpu load high even when all the torrents are paused?

[iyttahmimsyafu]

oo Yes it does

[charles]

so if you start up ​http://transmission.xpjets.com/OLD/2009/05/Transmission-1.61+0-svn-r8393.dmg with all torrents paused, there's no problem.

if you start up ​http://transmission.xpjets.com/OLD/2009/05/Transmission-1.61+0-svn-r8395.dmg with all torrents paused, it's got a high load anyway.

is that correct?

[iyttahmimsyafu]

No, the other way :P If I stop the torrents the problem goes away.

[charles]

I thought you just said the cpu load is high even when the torrents are paused...?

[iyttahmimsyafu]

Sorry, I somehow misunderstood you question. I need some sleep :P OK, if I start up any of the "affected" builds with the torrents paused; the problems is gone

[iyttahmimsyafu]

I just tried 1.70, I launched it and let it run for a while and when I looked at its stats in Activity Monitor, it was using ~120% os the CPU and 1GB of RAM and rising.

I ended up "Force Quitting" Transmission.

[iyttahmimsyafu]

Hmm… the crash log is too big for trac and pastebin

​http://b5.s3.p.quickshareit.com/files/crash7e69c.log

[nick2k3]

Hello, here's my shark report, ​http://transmission.pastebin.com/m7959e05a I've been experiencing high CPU usage doing the following steps, hope it will help: 1) set Max Connection Number to a reasonably high value (200 / 250) 2) wait few seconds, 3) decrease it to 100 or less cpu goes up at 80 - 100% on both core. I noticed this behaviour with the latest stable 1.70, and nightlies : 8569, 8589, 8604. though the report is based on 1.70 running a very popular torrent.

[nick2k3]

one little more details: the problem occurs when decreasin to values less than 80 connection.It is quite discrete: 79 connections -->high cpu usage and many system calls. 80connections --> all is fine.

using 1.70 on OSX 10.5.7. The problem also manifested to a user in chat using GTK+

[charles]

nick2k3: The thing about that shark trace, is there's still no tr_ API calls in it, so there's no indication how it's coming from Transmission.

[charles]

nick23k: based on comment 16, could you try r8393 and see if it has the problem too?

[charles]

Possible fix is in r8636. Please give the nightlies a spin and let me know how it goes.

[charles]

08:46 < stdisease> No more cpu spikes :)
08:47 < charles_> in r8636, you mean?
08:47 < stdisease> charles_, yes
08:47 < charles_> yay

[iyttahmimsyafu]

Yes, I can confirm this if fixed in 8636 :D

[nick2k3]

confirmed fix! good work!