Jump to content

uTorrent 3 high CPU usage


dryden

Recommended Posts

  • Replies 107
  • Created
  • Last Reply
  • 3 weeks later...

Hi,

I myself came across this problem. Searched a lot but found nothing. SO I finally came up with the solution. I went to the folder "%userprofile%AppDate\Roaming" (for Win7 users), and deleted the folder uTorrent. Then I deleted the exe from Program Files and reinstalled the stable version. Thats it. Remember, this will delete any ongoing downloads record. But they can be resumed by opening the .torrent file again of the same download. Thanks and enjoy!!!

Link to comment
Share on other sites

  • 4 weeks later...

This might be easier for some folks: In the advanced settings as above, mine was set as true, changed it to false (reset) then went back to true (reset,again) ant it lowered CPU load significantly. Win 7 ultimate, 32bit, uTorrent 3.1, Comodo internet Security. Windows may change things arbitrarily, if you use System restore, etc.:cool:

Link to comment
Share on other sites

  • 2 months later...
  • 5 weeks later...

I am on 3.1.3 and the high CPU and unresponsiveness seemed to be caused by a torrent that was displaying an error in the status column. After removing the torrent from the uTorrent list the CPU usage went back to normal.

I am sorry I can not offer anything to reproduce this problem. When I loaded the torrent into uTorrent (after removing), it started checking, downloaded a bit and seems to give no problems anymore.

Link to comment
Share on other sites

  • 3 weeks later...

(hope this is the right place to post this again)

Have the same problem with high cpu!

I go to applicationdata/roaming/utorrent but i don't see any setting.dat file.

I see 4 folders (apps, Cache, dlimagecache, ie) from which Cache and ie are empty, and all the torrents i've ever added to utorrent.

(the size of them are 71MBs in total)

I paused all utorrent activity, but still it can go from 15-30%!

I'm running utorrent 3.2 on Windows 7 x64, and I have Panda Internet Security

if i uninstall utorrent and delete the folder in application data, i guess every activity in utorrent (uploads and downloads) will be deleted too, right?

It's just that i have so many torrents uploading (around 60) from a a dozen sites, and can't put again each one..

Link to comment
Share on other sites

But i have Panda for years and use utorrent too.

This problem is in the last few weeks..

So, it couldn't be Panda

hmmm..

Now i have only one torrent downloading at low speed.

the cpu usage is 36-40% when I put utorrent in fullscreen, and drops to 1-3% whenever I minimize it and have it in the tray.

So, i guess that's normal?

I don't remember if the high cpu usage when i downloaded 4-5 torrents at max speed was only when i had it in full screen, or minimised in the tray too. I will have to look at it..

Link to comment
Share on other sites

  • 1 month later...

Hello

I've investigated the problem in subj and found 1 100% reproducible factor (of how many?) which leads to high CPU usage and freezing UI.

Conditions:

  1. OS: Windows 2003 Server SP2
  2. uTorrent 3.2.1 which I get on "standard way" from http://www.utorrent.com/intl/ru/downloads/complete/os/win
  3. Screenshots with CPU usage history for 12 minutes were acquired for uTorrent minimized to system tray to exclude UI overhead.
  4. A time period between setting up uTorrent process to required state and acquiring screenshot with CPU usage history is 20 minutes.

But the found factor is for uTorrent v3 (not only 3.1.2 or 3.2.1) and does not depend from OS (see

my previous post with observations on uT v3.1.2 and Win2k SP4, which were acquired on the same torrents set, but the factor left unknown).

[h]First, let's look at the PE Performance Graph tab with CPU usage by uTorrent 3.2.1 process.[/h]

uT process in high CPU usage state:

212398078.gif

Full size image

One can see

  • the highest green peaks with average height 60% CPU usage (5.5 cells, under red pillars) with average period 19 grid cells (6*19=114 seconds) between them
    and
  • the more frequent red pillars with repetitive lengths of 2-3 cells and heights of about 3 cells.

Then I change something in this uTorrent process, wait for 20 minutes and get the following CPU usage history.

uT process in normal CPU usage state:

212398079.gif

Full size image

There are no more red pillars which show high CPU usage in kernel mode.

All what I did I stop torrents with huge file list. Also this torrents does not produce any valuable upload traffic (checked by number of peers and upload columns).

I repeated this experiment 3 times for 3 independent uTorrent processes (one process at one time) on the same machine, OS and winlogon session to check reproducibility.

[h]Second, let's look at the some characteristics of those "huge file list" torrents and compare them with some others to check the hypothesis.[/h]


# Number Size Link
1 4625 31 GB http://rutracker.org/forum/viewtopic.php?t=469305
2 10644 17.4 GB http://rutracker.org/forum/viewtopic.php?t=1407513
3 8908 8.28 GB http://rutracker.org/forum/viewtopic.php?t=1439082
4 9680 10.0 GB http://rutracker.org/forum/viewtopic.php?t=1453442
5 11495 15.2 GB http://rutracker.org/forum/viewtopic.php?t=3014414
6 342 4.01 GB http://rutracker.org/forum/viewtopic.php?t=1818439
7 607 3.38 GB http://rutracker.org/forum/viewtopic.php?t=2690353

# - the local id of the torrent.

Number - the number of files in torrent.

Size - the total size of files in torrent.

Link - the source of torrent file.

This 7 torrents contains music and topographic maps in GIF format.

Let's compare with other torrent with big total file size and small number of files:


# Number Size Link
8 34 41.2 GB http://rutracker.org/forum/viewtopic.php?t=2566619

This total size of files in this torrent is 41.2 GB, but it was run when the second picture with CPU usage history have been acquired. Also the survey was used other 90 running torrents at the same time with average file size 500 MB and 2 file per torrent in average.

Hence this 1 found factor which leads to high CPU usage

  • is the huge number of files in some torrents
  • and does not depend on

  1. OS or
  2. total size of files in all torrents or
  3. traffic.


    [h]Third, let's investigate the freezing UI considering to huge file list torrents.[/h]
    After acquiring the second picture 7 listed huge file list torrents left stopped and uTorrent minimized to tray.
    The following actions show the correlation between this torrents and freezing UI:
    1. Open uTorrent window
    2. Select 7 listed torrents in UI
    3. Start them and wait ))))
    I waited for 1 minute 34 second while UI become responding to mouse actions.
    After this delay all 7 torrents were running.
    [h]Conclusion[/h]
    The 1 found factor which leads to high CPU usage and freezes UI is the huge number of files in some torrents. Minor version, OS, total size of files in torrent or traffic did not have a strong influence in selected conditions.
    And now, devs, you can use the conditions, test data and reproducible effect described in this survey to find and burn pieces of code where algorithm sucks on huge number of files in torrent. Good luck :-)
    Thanks for your attention!
    Any questions?
Link to comment
Share on other sites

Conclusion

The 1 found factor which leads to high CPU usage and freezes UI is the huge number of files in some torrents

+1 !

I believe the root cause is internal files not being aligned to 16KB boundaries, thus huge # of read-modify-write operations.

My belief is that a special cache for those 16K edge piece - can solve the issue!

Link to comment
Share on other sites

  • 2 weeks later...

So, my initial thought was that this could be caused by the problem in 3.3 where we end up flushing a lot of 16 kiB blocks to disk. If the assumption is that torrents with many files means most of the pieces are not aligned to file blocks on the filesystem, this would make sense (but that relies on the inverse being true as well; that the torrents with few files have the main file as the first file, so that most pieces are aligned).

This would also explain why the majority of the CPU usage is red (which I assume means kernel CPU time). Since it's the kernel that needs to deal with the unaligned, small, writes.

However, it doesn't explain why this would manifest itself in 3.1, where we still use the old disk cache algorithm in a single thread. The fact that the torrents that don't trigger this problem still don't appear to have the majority of pieces aligned, also suggests that this is unrelated to aligned v.s. unaligned reads/writes.

I ran the following test on Windows 7:

1. I generated a test torrent with 1000 files, each about 5 MB each (the sizes were deliberately made so that the pieces would not be aligned with the files). The test torrent ends up being 5 GB in total.

2. Download this test torrent from 50 test peers over loopback, with default settings except bumping the cache size to 128 MB.

3. The download rate hovered around 10 MB/s (it's a fairly weak machine, especially its harddrive). The CPU usage was steady at below 10% for the duration of the test.

4. The average size of writes to disk was about 100kB (with 1 MB piece size), so write coalescing did happen.

I also ran the same test but uploading to 50 peers instead of downloading. The upload rate hovered around 15 MB/s, and CPU usage very low at around 1 - 2% (since there's no hashing when uploading, there's less pressure on the CPU).

Now, the fact that I can't reproduce this could be explained by any of these reasons:

1. windows 7 doesn't exhibit this problem

2. 1000 files is not enough to trigger it

3. you have some specific configuration option set that triggers this issue

4. some driver of yours doesn't like certain kind of load (say, unaligned disk writes)

My guess would be that it's either 1 or 3. Given that the CPU that's being used is in the kernel, it's probably some specific system calls with some specific options that trigger it.

Would you mind sharing your settings file?

Also, do you see this load even if you're not downloading anything? (say, if you start all these torrents but set a download rate limit to something low). If not, does the CPU usage seem to be proportional to the download rate?

I guess my next test should be with 100 test torrents.

Also, the spikes of green CPU usage you see (in both cases) coupled with spikes in I/O, that's when we save the resume.dat file. This is not done very efficiently, and I'm hoping to be able to fix this at some point.

I'll keep trying different configurations to trigger this. Please let me know if you have any thoughts of what other properties that may be correlated to this mis-behavior.

Link to comment
Share on other sites

I also didn't notice any special CPU % load with my Win7. This is also not a good measure when you try to compare. You need to consider only the overall (over the whole download, or per gigabyte of file) of CPU consumption, so to take the CPU type partly out of the equation. Sadly, I also reached the same *poor speed* result you did.

My concern is this poor speed you/I am seeing here, not even close to the disk write speed capability. In my opinion - doing the test over a loopback is not good. You mix up seeds & peers activity of reads/writes, usually to the same HD.

You should be using a 1G LAN (as I do), and ideally, should reach a speed close to your HD capability (~40-50MB/sec). This is what you can get when you copy a file in Windows... If you don't (even for a single file), than uTorrent is capping it. And you don't! BTW, older releases of uT with a single (aligned!) file - did reach a speed very close to this! Using multiple-files torrents, resulted in ~50% speed drop (over LAN), which clearly proves you do have an issue with reaching the top possible speed when handling those!

I might try using Windows performance monitor, try see if it can shed some more light. Oh, and you forget a 5th option - a uT bug/poor-design... ;) Maybe stopping to write the resume.dat file ? ... :P We can try to just increase the advanced option for the resume write rate to 99999...

The only question here is - why uT is doing that, and how to improve on it. Can you please try to cache edge 16Ks, and not use 16K sized writes when a piece size is >512K...

Link to comment
Share on other sites

Rafi, I'm using a benchmark tool that deliberately does not read any data from disk. The test torrent consists of predictable data that the benchmark tool can generate on the fly, so there should not be any contention over the disk. Also, the machine I'm testing on does have a pretty slow drive, I don't think it can do much better (at random access writes). This is a version of 3.3 with the cache flushing issue fixed as well (we'll release it next week).

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...