High CPU utilization when paused

[JakeR]

I am not sure if I have been able to come up with the exact scenario to duplicate this problem but it seems that I see a 20-25% CPU utilization even when Transmission is paused and not downloading or uploading.

The problem seems to occur if I change network subnets such as going from one location to another on my MacBook Pro, v10.5.8, 2.6Ghz Intel Core 2 Duo with 6GB 667Mhz DDR2 SDRAM. If am running about 10-12 torrents, mostly seeding, of my list of about 60 in either turtle mode or no, pause them to do other work, then sleep my MBP and move to a new location on a different subnet, Transmission will ramp up to this ~23% CPU and stay there. I notice it mostly because I hear the fans speed up.

I am trying to determine an exact step-by-step to duplicate but it seems almost random. Once this happens, it will likely continue to do this even if I stop and restart the app even with all torrents paused. Usually the app will take a full minute to quit if in this state and occasionally need to be force-quit. This seems to happen on an version that I've tried *after* v1.76, currently v1.91. Starting up v1.76, the update after which I started noticing the problem, will usually help but not always without a complete reboot.

Anyone else see ever see this?

Shark Profile: http://transmission.pastebin.com/m1ad9adb9

The only thing I could find in the console log for "transmission" was:

2/23/10 Feb 23, 2010 12:29:47 AM com.apple.WindowServer[73] aped[73]: Attach failed: 4 (BSD: system 0x0/0x0, err 4), for Transmission[27175]
2/23/10 Feb 23, 2010 12:29:47 AM [0x0-0x402402].org.m0k.transmission[27175] [00:29:47.651] Starting libevent thread
2/23/10 Feb 23, 2010 12:37:46 AM com.apple.launchd[559] ([0x0-0x402402].org.m0k.transmission[27175]) Exited: Terminated
2/23/10 Feb 23, 2010 12:38:47 AM com.apple.WindowServer[73] aped[73]: Attach failed: 4 (BSD: system 0x0/0x0, err 4), for Transmission[27203]

I suspect that the 12:37 entry is my force quit and the 12:38 entry is me trying to launch the app again and getting the same result.

Hopefully I have included everything that might help.

Thank you,
Jake

[livings124]

Do you have an application enhancer installed? That might be an issue.

[JakeR]

I presume you mean Unsanity or one of the haxies that depend on it? Like WindowShade X?

That is the only application enhancer that I am aware of. Consider it removed if you suspect that is the issue.

j

[JakeR]

Window Shade X and Unsanity eradicated but the problem persists. From a fresh reboot, start Transmission. Put the MBP to sleep, bring to another location (aka completely different subnet and network path to inet), wake it up and, immediately before other things (like iChat and Skype, for example) can connect, already Transmission is 20-30% and will stay there. I am working on making sure this 100% duplicable - at least on my machine.

This suggests, possibly, that it is not so much the network location as the app disliking going to standby and then waking up again. Unless some hidden traces of Unsanity exist or another application enhancer that I am forgetting or otherwise unaware of still exist.

I welcome any suggestions.

Thank you.

j

[JakeR]

I thought of that but none of the current torrents are listed as verifying. In fact only 2 of the list were active went it went to sleep and when it woke up.

I verified this behaviour by going to a third location and the problem reoccurred.

j

[JakeR]

Must be a more general thing since it seems that even if I just start up the most recent version of Transmission with everything (48 torrents, some local some on connected external drives) paused and nothing verifying it seems to sit around that 23% CPU mark. If I startup most/all of the torrents, CPU will go up to 70-90%.

I thought that maybe it had to do with the data being on the externals (one is Mac OS Extended (Journaled) and one is NTFS via the NTFS-3G driver) so I moved any NTFS-3G to the Mac OS Extended volume - no change.

Is there a way for me to determine what Transmission is so busy doing? Shark? I am new to figuring this out at the process level on Mac OS X...

[JakeR]

Interestingly, I deleted *all* my torrents - thinking that perhaps the sheer number (even if they were all but one or two paused) was irritating Transmission. I started off with three completely new ones and thought the %CPU for Transmission hovered around 10-15%. I added 6 more after the first three came in and now it floats around 16-28%. Of the nine total, now 6 are just being seeded. and three are trickling in.

If I pause all transfers, Transmission CPU percentage oscillates between 10-20% which seems really strange for a application that should be doing nothing - no verification either that I can see.

Are those kinds of CPU numbers normal?

[JakeR]

Thank you for responding... I thought I was going nuts so it is most good of you to confirm my suspicions.

I tried disabling DHT (distributed hash table) first in Transmission->Preferences->Peers section but there was no difference - cpu% for Transmission continued to be oscillate between 17-42% with the fans on my MBP kicking not-quite-full-speed (4800RPM) and little else running - still in 64-it mode. As it made no apparent difference, I re-enabled it.

Get Info -> Opening in 32-bit mode *did* make a resounding difference. Transmission CPU% was between 4-13% with the same 9 torrents running, 7 of which were seeding and Activity Monitor verified that the app had restarted NOT in 64-bit mode (note OS 10.5.8), percentage min/max observed over a 90 second period with even one likely anomalous peak at 26.7%. Testing disabling DHT again made no apparent difference while the torrents were running. If I paused all torrents I see a Transmission CPU% between 1.5% and 8.7% which still seems pretty excessive.

I was thinking that a clean reinstall might be best but I am not sure what the recommended uninstall process is. Should I use something like "Clean My Mac" or "AppCleaner"? In the meantime, I simply replaced the Transmission.app in my applications folder with the nightly build and verified that all the symptoms described so far were present in v1.92 as well as the nightly build.

The only thing in Transmmission->Window->Message Log is an error about an "unrecognized host" though the torrent is slowly coming in which is why I left it running:

2010-04-18 01:07:23 -0400 torrent.c:343 [Error] Stephen R. Donaldson - Complete Thomas Covenant Chronicles: Tracker error: "Unrecognized host (http://www.xxx.yyy.zzz). Please go to http://www.myanonamouse.net to sign-up or login."

I presume this is because I am not a member of myanonamouse.net though the torrent continues to download - I had not realized this was a myanonymouse specific torrent...

No problems tracker announcing or any timeouts that I am aware of.

I think I did this correctly per your instructions in using Activity Monitor to Sample the Transmission process as well in posting the results to postbin.com.
Postbin Sample of Transmission Process (32-bit mode, all torrents paused):
http://transmission.pastebin.com/uQwKc7jD

Postbin Sample of Transmission Process (64-bit mode, all torrents paused):
http://transmission.pastebin.com/aWg29HCg

Both occurrences (32-bit and 64-bit) were demonstrating their higher CPU% numbers at the time of Sampling.

The only thing I could find in Console was in the general Console Messages that seemed to be a message corresponding to each time I started Transmission this evening during the gather of this inforamtion. I did not see a specific Transmission debug log and, with my apologies if I am missing the obvious, do not see how to enable a debug log:

4/18/10 Apr 18, 2010 12:41:36 AM [0x0-0x102102].org.m0k.transmission[3662] [00:41:36.156] Starting libevent thread
4/18/10 Apr 18, 2010 12:56:45 AM [0x0-0x10c10c].org.m0k.transmission[3763] [00:56:45.068] Starting libevent thread
4/18/10 Apr 18, 2010 1:11:01 AM [0x0-0x112112].org.m0k.transmission[3815] [01:11:01.346] Starting libevent thread
4/18/10 Apr 18, 2010 1:39:41 AM [0x0-0x11f11f].org.m0k.transmission[4320] [01:39:41.941] Starting libevent thread

No assertion failures and this is not a crash that would generate a crash report as per the instructions you linked.

Thank you again sincerely for your assistance and if you can educate me further as to where I might look to identify what is going on, perhaps more independently, I would greatly appreciate it.

Jake