Transmission causes leopard slow death

[cmlawson]

This slow death thing is affecting me. I thought it was the hard drive going bad this whole. Whew! Glad I discovered this thread.

[smajor]

Question for smajor and cmlawson, are you using 'Speed Limit mode' and/or DHT? Also, what are your global and per torrent connections set at?

Please provide OS version and Transmission version and build# when posting. Thanks!

Transmission Nightly 1.92+ r10415
Speed Limit Mode = Yes, daily from 7am to 10pm. Otherwise, wide open - no limit.
DHT = Yes, accidentally. I normally don't, at least when I had Vuze. It's off now and will likely stay off unless needed.
Global = 800
Per Torrent = 80
OS = 10.6.2 (10C540)

[smajor]

Okay, how's it going? If you experience lsd, try running without 'Speed Limit Mode' enabled and reduce connections to 100/10. Also please indicate whether you have tried "the fix" posted by parodyr. Please let us know what happens and what settings were in use at the time. Thanks!

So far so good with the nightly. It'll be a bit before I "see" anything, I run it on what I use as the house server so I typically don't notice any slow down unless I do something with it. I usually find out when it's just about unresponsive or completely so.

The good news is that it's an extremely stable system otherwise (before the LSDs it was only ever rebooted for OS updates), doesn't have a bunch of other apps on it - so it's good to test this out if it helps. I certainly don't mind!

[smajor]

Okay, how's it going? If you experience lsd, try running without 'Speed Limit Mode' enabled and reduce connections to 100/10. Also please indicate whether you have tried "the fix" posted by parodyr. Please let us know what happens and what settings were in use at the time. Thanks!

So far so good with the nightly. It'll be a bit before I "see" anything, I run it on what I use as the house server so I typically don't notice any slow down unless I do something with it. I usually find out when it's just about unresponsive or completely so.

The good news is that it's an extremely stable system otherwise (before the LSDs it was only ever rebooted for OS updates), doesn't have a bunch of other apps on it - so it's good to test this out if it helps. I certainly don't mind!

Since my last post everything was going great. I did have a lock-up yesterday and had to reboot. Unfortunately, my display had gone into power saving mode and I wasn't able to see what was on the display so I can't confirm that it was actually Transmission at fault. I couldn't find anything in my console logs to show either way.

I'm updating to the latest nightly as of this post.

Question: is there any detailed logging I can enable, maybe via a cli flag at launch, that might help?

[Alixa]

Transmission 1.92 (10363)
OS X 10.5.8
MacBook Pro 2.8 GHz Intel Core 2 Duo 4 GB RAM

I've used Azureus/Vuze for several years, but decided to try Transmission again.

With no software or hardware updates or changes since using Azureus, my system became unresponsive three times in one day. Activity Monitor showed SystemUIServer, Transmission, Safari and Snak (IRC) as not responding.

I'd had 150 torrents in Azureus, but only moved 25 to Transmission.

Transmission's peer numbers were set to the default 200/60, which I was using in Azureus. Other settings were also comparable. PEX and DHT were enabled, but all torrents were on private trackers. Download and upload speed limits were set to 300/62 K. Speed limit mode was not enabled.

After all the reboots, and with very little running other than Transmission, Snak and Safari, I didn't expect to see so much inactive memory used in Activity Monitor. I normally see a good bit of green in the pie chart, even when I haven't rebooted recently. Running Transmission left only 11 MB free. I'm not saying this is a problem, only that it seemed unusual.

I've disabled PEX and DHT.

I haven't tried the fix yet.

[bjdprivate]

System Version: Mac OS X 10.5.8 (9L30) Computer Name: DEECD_MacBook_V3 (3)

HI I've just read through this thread and it seems there is not an answer to this problem. I have been using Transmission for about 5 years now without any problems. Now i can't seem to use it more than half an hour and everything freezes. my kids are screaming at me and I'm getting a headache. Is this problem going to be addressed in the next release or should i start using azareus (which I just don't like)?

[countach]

I've starting getting this problem quite a bit lately and stumbled onto this thread. Can someone give a status of what I should do? I can see mentions of people changing kernel parameters, unloading vmware, updating transmission versions, reducing speedlimits, changing connection limits. What should I try first?

And whose problem is it? I would report it to apple if I knew for sure it was their problem and how I would even go about describing it.

[countach]

Is there any explanation of what these changes do? I like to have a rough idea of what I'm doing before changing stuff like this. And does this cure it or just reduce it?

If any Transmission developers are here, can I suggest that they add the option to throttle speed via number of connections? It wouldn't be as accurate, but better that than crashing the machine. I know I can manually change number of connections, but that removes the time limit features and the ability to just click the turtle button.

[Jordan]

If any Transmission developers are here, can I suggest that they add the option to throttle speed via number of connections?

One of the Transmission developers here put out a call about a month ago for people to test the nightlies because they have a new automated throttle system.... but that request was ignored except for one user....

[smajor]

My Mac has been up 17 days straight since my last post using the nightly build I mentioned in the above post. For me, things look good. When next I reboot for the recent Apple security update, I'll probably jump on the latest nightly.

[petter]

I've tested the nightlies as well as the last official release.

It dies for me only when I'm running a larger amount of added torrents no matter if the torrents are on pause or running.
It consumes the memory fast which in the end causes different processes to run short on memory one by one untill it halts completely.

System: 10.6.3
Macmini; 2GHz C2D
Memory: 1GB

Transmission: Transmission-1.93+Z-svn-r10629
Tunneled over OS X VPN

Transfers: 27
Active: 2
Paused: 25

Free Memory just after login and launch of VPN and Transmission: 469 MB
3-4 minutes after that no free memory is left and one by one of the processes halts.
System clock and VPN timer are still ticking though for some time but computer cant be controled either by ARD or locally untill it comes to a final halt.

If I erase a larger number of the transfers it will keep running without any problem what so ever.

[badsyntax]

transmission freezes my OSX 10.X (currently on snow leopard, but same for 10.5), and only if there are many LARGE torrents (6gb+). if the torrent downloads are fairly small, there is no problem.
i'm also not sure at what point my OS freezes, it seems random to me. it will be fine for many hours, but will freeze sometime thereafter. transmission is the only software on my mac that feezes my OS. using transmission 2.04 (11151)

[r0n1n]

transmission freezes my OSX 10.X (currently on snow leopard, but same for 10.5), and only if there are many LARGE torrents (6gb+). if the torrent downloads are fairly small, there is no problem.
i'm also not sure at what point my OS freezes, it seems random to me. it will be fine for many hours, but will freeze sometime thereafter. transmission is the only software on my mac that feezes my OS. using transmission 2.04 (11151)

This is probably caused by heavy disk i/o, the developers have added a memory cache in the nightly builds (scheduled to be added in the stable builds in 2.10) to solve this problem. You should try a nightly build and see if that solves your OS lock ups.

[msandersen]

OK, I ran into this problem just recently after updating my Snow Leopard system with a security patch and restarting. I'm not sure if it has happened before; I've had some slowdowns on the odd occasion, but not sure if Transmission was running. This time it seemed clearly linked with Transmission and using the "turtle" speed limiting mode, which i've used before without issue. The symptoms were as described my many others; open applications continued to work, while the finder (and Dock) became unresponsive, with no new programs being able to launch. open applications that tried to use the Finder via the save dialog would similarly freeze. It was repeatable and consistent connected with the "turtle" mode.
I googled and found this thread among others and bugtracker ticked #1201 ( https://trac.transmissionbt.com/ticket/1201 ). Reading up on it, I downloaded the latest nightly (build 11187), disabled DHT (I'd turned it on recently to see if it would add more Peers; it is an advertised feature, so must be good for something), and reduced the Global and file limits form the default 200/60 to 100/10 at first. It worked, and my system was stable again. I did not apply the Parodyr sysctl fix, but did read up on what it is. I've since experimented a little, upping the limits a bit, first the Global limit, then the File one. At 180 for Global, it seemed too much though, as the Turtle mode froze it again. This time I was running iFreeMem to keep an eye on things, and though Free memory was low as opposed to inactive memory, there was no great movement to eat available memory. I lowered it down to 160/20, but was eventually able to destabilise the system, tho a bit slower. From when it has happened while running iFreeMem, it appears it has nothing to do with memory being eaten up. Once it appeared like I was able to quit Transmission, but it was still too late with the Finder becoming unresponsive and the network being down, and my Adium freezing up.
I read a post somewhere here that they had found out it was the Yukon Ethernet chipset on the motherboard which was causing the problem, and that letters to Apple seemed to confirm it along with his crash logs. If so, whether defective hardware or drivers, the best Transmission can do is try and mitigate the trigger. From my reading, reducing the limits doesn't help everyone, nor does the Parodyr "fix" while it does for some. Personally I would not want to mess with those settings too much, and certainly wouldn't want Transmission to set them on install without more being known.

iMac 8.1 (2008), 2Gb RAM, Snow Leopard, downloading to external Firewire800 drive.

An interesting article on sysctl on the Mac, though from 2007: http://www.macgeekery.com/tips/configur ... _revisited
To check what your current settings are, simply use the sysctl command in Terminal with the appropriate control, like:
sysctl net.inet.tcp.sendspace
The only values I have put in my /etc/sysctl.conf file so far is:
net.inet.tcp.mssdflt=1440
net.inet.tcp.win_scale_factor=8
Information on it was scarce, and sometimes related to FreeBSD systems, and usually for improving local network performance, especially over Gigabit ethernet. I only have a PC and a router on my network other than my Mac, both with regular ethernet, and one Firewire800 external drive, so it is not practical for me to test optimal settings. There are a few posts about someone's optimal settings, but they vary substantially.

[Inuyasha]

transmission freezes my OSX 10.X (currently on snow leopard, but same for 10.5), and only if there are many LARGE torrents (6gb+). if the torrent downloads are fairly small, there is no problem.
i'm also not sure at what point my OS freezes, it seems random to me. it will be fine for many hours, but will freeze sometime thereafter. transmission is the only software on my mac that feezes my OS. using transmission 2.04 (11151)

This is probably caused by heavy disk i/o, the developers have added a memory cache in the nightly builds (scheduled to be added in the stable builds in 2.10) to solve this problem. You should try a nightly build and see if that solves your OS lock ups.

Using the latest nightlies, Transmission still causes an enormous buildup of inactive memory, and depending on I/O levels that can cause freezing of the main TM process, and the OS writes/reads to the RAM cache like crazy. The client also takes 5-10 minutes to quit.

(I've typed this same exact thing like 50 times over two years)

OSX 10.6.4 with networking chipset: 13:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 03)