µTorrent 2.0.2 released

[Firon]

We used to close files every 2 minutes no matter what. Now we only close "old" unused file handles to avoid access denied problems. This triggers the Windows caching problems. It can happen with both the read and write system cache.

Now we flush the files (not close) every so often, which just tells the OS to write all buffers to disk. I don't know what effect it has while reading. Presumably it'll prevent the same problem.

[newuzer]

Firon:

The change is basically that we don't close all files every minute now so we can lock them and prevent the stupid access denied errors that have plagued uTorrent for ages.

But this makes Windows cache more aggressively. Honestly, I haven't noticed it to be a performance problem, though I've seen sporadic reports that it can (and disabling Superfetch makes the problem go away permanently, though I don't know at what cost).

Now, why was it so hard to tell this now, after all the explanations (ranting) about different behavior between releases?

IIRC I've seen SuperFetch in the svchost.exe memory eating process.

It definitely could explain this behavior.

Disabling SuperFetch will affect overall system performance.

NU.

[rafi]

I got that, Firon ... thanks

Me:

can you just explain again what it does and under what conditions ?

...

Doesn't it, in effect, make the cache useless , since the cache should be doing the flushing ?

And another question - since working with uT cache was fine, do you do that flushing only on condition that Windows write cache was enabled by the user ?

What do you think ? can it be done conditionally ? Since I do want the uT cache to be effective! Maybe just for certain OSes or X64 modes ? or by some setting ?

[newuzer]

IIRC I've seen SuperFetch in the svchost.exe memory eating process.

It definitely could explain this behavior.

Disabling SuperFetch will affect overall system performance.

Scratch all that.

I'm testing the 2.0.1 testversion now and memory usage is still going to the roof.

In about an hour it steadily climbed to near 100% of 4GB total memory usage and the system becomes less responsive.

The svchost.exe process is not to blame, which was my mistake (sorry for that).

There is no visible process that uses the amount of memory.

There was a sudden drop of memory to 2.6GB total usage after about an hour and a half or so, but it steadily climbed back up again.

For comparison: I Tested an old version (v1.8.1) yesterday, which kept memory usage to 1.6GB total at much higher upload speeds.

NU.

[rafi]

@newuzer: a shot in the dark - try disabling the speed-graph legend (gui.graph_legend=false) if you have it on ...

[Firon]

Are you seeding or downloading?

[newuzer]

Seeding only.

NU.

[nanodesu]

Seeding in 2.0.1 seems terribly broken.

Testing 2.0 (18488):

Then switch to 2.0.1 (19078):

Then back again to 2.0, just to be sure:

Calc.overhead is disabled, bandwith management and tcp_rate_control is enabled. All other settings and torrents are the same. No limits are set.

[rafi]

hmm. no upload ... strange. why is net status not green for both apps ... ? how about using some UL limit ?

[prodigydancer]

I confirm that 2.0.1.19078 causes abnormally high memory usage (in my case the affected system was Windows 7 x64 Enterprise).

Reverted back to 2.0 until this bug is fixed.

[Firon]

Turn on "Disable Windows caching of disk reads."

[osm0sis]

I'm having issues where I'll click X to close uTorrent, the window will disappear as though it closed (though sometimes there's a substantial wait on that) and then hours later I'll discover utorrent.exe is still a running process in Task Manager - no CPU and next-to-no memory usage (3mb) but it doesn't respond to End Process requests.

[Firon]

Yes, that's a known Windows 7 issue. We think it's an OS bug, and we are working on it. Follow this thread: http://forum.utorrent.com/viewtopic.php?id=71296

[osm0sis]

Great, thanks!

[nanodesu]

why is net status not green for both apps ... ?

Because my ISP uses NAT, and sometimes it's green, yellow or even red. It doesn't really matter, because 2.0 (and earlier versions) works fine.

how about using some UL limit ?.

I'll try to do more testing when I have time.

[badschandau]

Is it safe to upgrade from 2.0 yet? There are two things that make me cautious.

The first is about the XP-compatibility. According to various forums here it seems that XP users should patch their system somehow or(and?) set "net.max_halfopen" to 8 . Also, "bt.connect_speed" to 5. Neither of these are the default values.

Also, what about the alleged memory leak? Not only here but at other forums (on private trackes) I read about this. Does it exist in the first place, and if so, also on XP (Home) systems?

[prodigydancer]

Turn on "Disable Windows caching of disk reads."

Will it affect only uTorrent? If yes, it's a good solution. But if it's a system-wide change, it's unacceptable, sorry.

[rafi]

it should be effecting only uT. I have it disabled for ages (on XP/X32, though). Alternatively, I would also try to *manually* limit the cache to 32M.

[acmodeu]

Finally, with that setting enabled memory consumption is over! Firon, thanks for the hint.

[stevvie]

µRemote 2.3.2 doesn´t work with µtorrent build 18973 and newer it worked fine in build 18833.

also the iphone app uremote 1.3 doesn´t work with µtorrent build 18973 and newer it worked fine in build 18833.

SAME problem t-xdk had on page 4 of this thread. Also noticed this

a few times 49% CPU usage (thats all of 1 core on a E6600) Tried quitting Utorrent and waiting for the utorrent.exe to go from task manager then restarting it but still at 40+%. NONE of my files are rechecking or anything when I get his.

[Firon]

stevvie, µRemote is broken. It needs to be updated.

Is it safe to upgrade from 2.0 yet? There are two things that make me cautious.

The first is about the XP-compatibility. According to various forums here it seems that XP users should patch their system somehow or(and?) set "net.max_halfopen" to 8 . Also, "bt.connect_speed" to 5. Neither of these are the default values.

Also, what about the alleged memory leak? Not only here but at other forums (on private trackes) I read about this. Does it exist in the first place, and if so, also on XP (Home) systems?

This isn't a real memory leak (or at least, not one that's our fault), but a problem with the Windows cache manager. It affects any app that works with large files and uses buffered I/O... but it's worse with µTorrent because we open more files and keep them open for longer. We're contemplating turning on the bypass of the system cache for reads, but we don't know what the performance penalty would be.

net.max_halfopen defaults to 8 on XP and Vista pre-SP2 still. It's 400 on any other platform, since they have no limit. You don't need to patch anything.

Turn on "Disable Windows caching of disk reads."

Will it affect only uTorrent? If yes' date=' it's a good solution. But if it's a system-wide change, it's unacceptable, sorry.[/quote']

This affects only µTorrent.

[mahs49]

I hope this thread is not strictly about uTorrent 2.0.1. If it is, please accept my apologies.

I have been having the high memory consumption problems with 2.1 alpha build 18959, up to 1.5GB out of 4GB total. I use Windows 7 x64 Ultimate. The problem happend regularly rendering uTorrent unresponsive to End Process through Task Manager.

On a few occasions it caused windows fail to Restart or Shut Down. uTorrent itself tries to send a crash dump everytime windows is re/booted but it always fails to send the report.

On a few occasions my PC failed to connect to the internet, troubleshooting suggesting DNS or ISP failures. I am not sure if this was related to utorrent.

I have read Firon's comments about malware and antimalware & firewall problems. I am not sure this problem applies to my system. I have avast! and Microsoft Security Essentials, PCTool's Spyware Doctor and SUPERantispyware with Windows 7 Firewall and the D-Link router NAT/Firewall. I do not think they cause any conflicts or have any related bugs.

I am now trying [Turn on "Disable Windows caching of disk reads."] as Firon suggested. I hope this will solve the memory and crashing problems.

If I need to send the uTorrent crash reports manually, could you please, Firon, tell me how to send them to you reliably.

[Firon]

This thread is strictly for 2.0.1. There's a thread for 2.1: http://forum.utorrent.com/viewtopic.php?id=63247

[nanodesu]

how about using some UL limit ?.

I did some testing and you were actually right about setting limit. See graph:

No limit - no speed. Set limit way above possible maximum and speed quickly goes up. Disable limit and speed goes down again.

I hope this'll get fixed soon, because I don't want to have limit enabled.

[rafi]

strange... probably something specific to your settings. It's surely not a designed behavior, more likely a bug ... maybe post your settings.dat. Someone in the devs department might pick it up and trouble himself to look at it...