Archived

This topic is now archived and is closed to further replies.

Firon

µTorrent 2.0.2 released

Recommended Posts

No, the svchost.exe process is using all the memory.

I decided to connect to IRC to try to get things sorted.

After disabling the read cache and restarting uTorrent, the memory usage is brought down to normal but IMO it also brought down the upload speed.

Firon@page#2:

newuzer: we disable it for writes, but for the vast majority of users, it's not necessary to disable it for reads. And in general, disabling the system caching is not the preferred solution, for various reasons.

Although changing settings seems to help make this version usable, I also think this is not the solution to the problem.

There is a difference between earlier releases and this release which causes it to use an intolerable amount of system resources, making it unusable for some of us.

NU.

Share this post


Link to post
Share on other sites

"No, the svchost.exe process is using all the memory."

Using Process Explorer, check that svchost.exe process's DLL list...does it contain antivirus or software firewall DLLs? (Those are often memory-killers when uTorrent is running.)

Share this post


Link to post
Share on other sites

Well, I can confirm memory leak problem in 2.0.1 stable on Windows 7 x64.

It occures after a short time and consumes all availiable memory making system unusable.

Previous stable build 2.0.0 doesnt have any problems.

Sry, didnt do any additional researches.

Doesnt have any AV soft installed except Microsoft Security Essentials, but again prev build works fine.

Share this post


Link to post
Share on other sites
Gabtendo:

Is there a bug that was found in 2.0.1 that is keeping it from being pushed to the main update server?

I guess the purpose of this gradual upgrades (betas only now) is to get an answer to your question... so, you should read this thread and judge for yourself ... :P

Switeck

"No, the svchost.exe process is using all the memory."

Using Process Explorer, check that svchost.exe process's DLL list...does it contain antivirus or software firewall DLLs? (Those are often memory-killers when uTorrent is running.)

more info from the IRC for the devs' attention:

[17:20] <12_rafi_> newuzer: http://forum.utorrent.com/viewtopic.php?pid=476986#p476986 

[17:21] <12_rafi_> could you confirm svchost used a uT dll when the memory problem occured ?

[17:21] <newuzer> process explorer?

[17:22] <12_rafi_> well, I think - by M$... but I suppose thta any process info tool will do

[17:22] <newuzer> I did have a look, but don't have the time atm to check any further

[17:23] <newuzer> it shows a lot of stuff

[17:23] <12_rafi_> ( --> http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx )

[17:23] <newuzer> yep, got that

[17:24] <newuzer> I don;t see any uT dlls in use

[17:24] <12_rafi_> you mean when the read cache is on ?

[17:26] <newuzer> yes

[17:27] <newuzer> I must say that I don't know exactly how to use Proces Explorer (yet)

[17:27] <12_rafi_> so, I suppose you can edit that into your post and we can call it a uT bug ...

[17:28] <newuzer> lol

[17:28] <12_rafi_> but....

[17:28] <newuzer> it's really easy to reproduce

[17:28] <newuzer> uT development can also do that of they want

[17:28] <12_rafi_> only IF you specify exactly what DLL DID consume the memory in that process ...

[17:28] <newuzer> I only want to point out the difference in behaviour

[17:29] <12_rafi_> I know... but others seem to want to "use" you as a helper to debug uT ... well they did give you a free app..

[17:30] <newuzer> lol

[17:32] <12_rafi_> and theoretically, newuzer, it CAN still be something specific on your system that does not interact well with uT ...

[17:32] <newuzer> I very much doubt that

[17:32] <newuzer> I'm not the only one with this problem

[17:32] <newuzer> my system is pretty basic

[17:33] <newuzer> v2.0 has no probs

[17:33] <newuzer> running it at this moment

[17:33] <12_rafi_> the fact is that the devs did try to emulate it , and were not successful

[17:34] <12_rafi_> ( as far as I know )

[17:34] <newuzer> all I did is seed 11 torrents @>1MB/s with Windows 7 x64

[17:34] <newuzer> seed only

[17:35] <newuzer> after about an hour or so, the effect is visible

[17:35] <newuzer> I think the seeding is importent

[17:35] <newuzer> other report they got it when downloading was completed

[17:36] <newuzer> and they were seeding afterwards

[17:37] <_rafi_> well, why not just post all that (instead of writing it here... ) . It might be of help to someone @devs-127.0.0.1... ;P

[17:38] <newuzer> I posted that

[17:38] <newuzer> several times

Share this post


Link to post
Share on other sites

Stock Windows 7 won't make svchost use all the memory, even while using uTorrent, so it's some service you installed. Probably broken security software.

Share this post


Link to post
Share on other sites

It doesn't with 2.0.

Too bad to hear these kind of dumb comments from you, Firon.

Anyway, I stop wasting my time here.

This software is b0rked and gets worse with every release.

NU.

Share this post


Link to post
Share on other sites

I use Windows 7 64-bit on multiple machines (at home and at work) and none of them exhibit these behaviors. None of them use any 3rd party security software, just what's built into Windows.

Process Explorer can tell you what services are loaded into a particular svchost instance by going into the properties of it and clicking on the Services tab. It can't tell you their memory usage, but it will give you a better idea of which one is causing it (look for non-stock services).

Share this post


Link to post
Share on other sites

1st link in my signature, last post, very last part of that tells how to get Process Explorer to show uTorrent.exe's DLL list. Since svchost.exe is using the memory, we're wanting to see the NON-Microsoft DLLs loaded under that svchost.exe

Share this post


Link to post
Share on other sites

I don't get it ppl. Why offense "newuzer"? No1 sees my message?

I wrote that I'm experiencing the exact same behaviour of 201. That didnt happen on 200. I have 4GB memory/Win7x64 and NO 3rd party sec software (i use MS Security Essentials). So what should I check about your "probably broken security software" suggestion, Firon, if I don't have any?

I'm going to run Process Explorer right now and wait till the issue occurs.

Edit: Ok, the memory consumption rased from 60% to 98%, but I don't see any process "eating" that much of memory in PrEx. There's definitely a leak, but how to identify where...

Share this post


Link to post
Share on other sites

The good thing about uTorrent in the past was that Ludde always aimed at making a small efficient program that uses as little resources as possible with the most features.

People loved that concept, hence the popularity of the program.

Well, the micro can now be removed, same as the word "efficient" on the web page.

If you, for example, compare v1.8.1 to v2.0 and v2.0.1, uTorrent has become a resource hogging torrent client in that short period. Totally inefficient.

Too bad.

NU.

Share this post


Link to post
Share on other sites

The Windows system cache eating system memory has always been a problem, even in the ludde days. I should know, I was working with him on the problem back in the day. I don't think you know what you're talking about.

Now, you said your svchost process is using memory, which is different from Delfinok's problem.

Delfinok: it's the Windows system cache in your case, and unless it's actually affecting performance, you shouldn't care.

Share this post


Link to post
Share on other sites

Firon, if it wouldn't actually affect performance, I wouldn't write here on this!

Again, I haven't had ANY issues with "windows system cache" on 2.0 causing the system to leak all availiable memory without flushing. On 2.01 i have this issue and thats why I do care!

After I shut down utorrent app/process - it frees 50% memory instantly.. and the system gets back to normal.

I thought I would use 2.01's new fixed bandw manager finally, but I'm going now to install 2.0 back and disable this thing again.

Share this post


Link to post
Share on other sites

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).

Are you really sure you're seeing a performance problem, or are you just obsessing about free memory?

Share this post


Link to post
Share on other sites

Hmm.. Really, I don't know what to say more on that here..

2.01 doesnt run - system runs stable, 57% physical memory free

2.01 has started, more than 100 seeds, some leechs - system becomes unresponsive in an hour, 100% memory consumption, overall system performance goes to nothing, lags, programs starting for ages, cant work - usual symptoms of a memory eating process!

killed 2.01 process - system gets back to normal!

Period! Doesnt have anything more to add!

No, really, im not seeing a performance issue here, not at all. Just a whole god damn memory eating process! Do you have more serious questions, Firon, please?

Share this post


Link to post
Share on other sites

Firon, it is most definitely a performance-impacting problem, the same as newuzer, Delfinok, and a few others have reported.

I currently use Windows 7 Ultimate x64 on an AMD Athlon X2 3800 with 4 GB of RAM. My storage options include 2 WD Raptors in a striped RAID volume, as well as a WD Black 1 TB drive that µTorrent directs all torrent downloads to. I have also excluded my torrent folder in Microsoft Security Essentials.

For me, it began as soon as I opted to allow µTorrent to update itself to the first RC (2.0.1 Build 18833) as soon as it was available through the auto-update feature. It did not take long to notice that something was definitely wrong with my PC's performance after I would get home from work. As soon as I would sit down at my desk, the system would take an excruciatingly long time to open any applications, and the graphics refresh on the screen was incredibly sluggish.

Task Manager (as well as the All CPU Meter gadget) indicated that every last bit (literally) of my 4 GB of RAM was being utilized, and the reads/writes to and from the paging file was causing excessive thrashing on my RAID volume.

Restarting the PC would naturally clear up the problem, but only temporarily. If µTorrent runs for a few hours, the system resources are gradually consumed again. I have also witnessed the memory usage sky-rocket as soon as a torrent has completed downloading and begins to seed. Within minutes, system memory is completely saturated. Stopping that one single torrent (while leaving the other 30-ish active torrents alone) causes almost half of my system RAM to become released almost immediately.

µTorrent always runs 24/7 (has for years now), and this has never been an issue before with any version prior to the one I mentioned previously. The "fixes" suggested by other members have done little to nothing in the way of accomplishing anything worthwhile.

This is not about some people just being anal about how much memory is being utilized. It's about a single application causing the entire PC to become practically useless over a period of time... when it previously did not. Blame Microsoft's disk caching... fine. Blame a part of the OS that's never (in my personal experience) been an issue... fine. I suppose it's coincidence that Microsoft made these changes to their OS at the same time a new version of µTorrent was released?

I still use µTorrent, because I love the program. I honestly liked the direction that 2.0 was headed, until very recently. For now, I remain on 1.8.5, as it causes no issues with system performance (with identical user-selectable settings as the problematic 2.0.1 releases).

Share this post


Link to post
Share on other sites

Trust me, this problem isn't new. It's a years-old problem (and it's why the function diskio.flush_files exists). We just hacked around it before by closing all files every minute. Now we don't do that to fix some other problems, so the problem came back. Windows has always been broken in this respect.

Now, we have a theory that maybe just calling flush on the files might do the trick, instead of closing them, so we'll be testing that very shortly.

Share this post


Link to post
Share on other sites

Thank you very much for that explanation, Firon. I was not aware of any similar issues with previous versions. I would imagine perhaps more people would probably be complaining about this problem if so many private trackers didn't block the use of 2.0+ releases.

At any rate, thank you for listening, and I'm sure any measures taken to improve the performance and resolve the resource usage issues will be greatly appreciated by everyone affected.

I'm really looking forward to upgrading to the current versions very soon.

Share this post


Link to post
Share on other sites

With pleasure! Thank you for the quick reply. Almost an hour in, and so far, so good. I'm really looking forward to waking up tomorrow to the same results. :)

Share this post


Link to post
Share on other sites
Firon:

Try this build out

before I try test this patch - can you just explain again what it does and under what conditions ?

If I understood correctly:

1. in 2.0 you used to close/open files

2. in 2.01 (maybe cause of some 2.1 issues ? ) you've canceled that

3. then, issues began to show in some OSes under unknown conditions , when the Windows' cache was enabled (read ? write ?)

4. now, in this test-build you try to flush files every minute or so to bypass this

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 ?

thanks for the info :)

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.