bugmldonkey, a multi-networks file-sharing client - Bugs: bug #1555, Ressource starvation with high...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #1555: Ressource starvation with high source files causes several serious bugs

Submitter:  Invalid User ID <#12098>
Submitted:  Wed 30 Oct 2002 12:07:55 PM UTC
   
 
Category:  eDonkey-Plugin Severity:  3 - Normal
Item Group:  None Status:  None
Assigned to:  None Open/Closed:  Closed
Release:  2.00 Release: 
Operating System:  Linux Binaries Origin:  Binary from Savannah
CPU type:  None

Tue 02 Dec 2003 06:20:57 PM UTC, comment #2: 

This patch report is very old. If the bug still exists in current
versions please post a new bug report - spiralvoice

spiralvoice <spiralvoice>
Group administrator
Tue 19 Nov 2002 03:10:17 PM UTC, comment #1: 

I know exactly what you mean and I'm experiencing the same behaviour. I have set the max. upload rate at 10 kbyte/s and my Cable modem's max is 15kbyte/s. Unfortunately this maximum value gets reached whenever I download a high source file, meaning I can't even browse the web anymore.

Invalid User ID <#12689>
Wed 30 Oct 2002 12:07:55 PM UTC, original submission:  

Hello all, I think I found the bug which causes the following problems:

- very high CPU load
- very high memory load
- upstream limit exceeded
- high performance drop

In fact this all stems from the very same single bug. If you add a "high source" file to mldonkey (ie a file with 1000+ sources) then mldonkey starts to continously find all these sources and get their chunk list. This traffic WILL surpass any upstream limit and cause performance degradation if it saturates your upstream.

Also the many many sources mldonkey is continously asking will also cause a very high CPU and memory load. This behavour is INDEPENDENT of any value of max_sources_per_file (I've set max_sources_per_file to 500 and still mldonkey contacts far too many peers. It seems it tries to open up max_sources_per_file ACTIVE, OPEN connections. Also it always searches for more peers for that file)

Setting max_opened_connections seems not to help either (I've set it to 600 and still ressource starvation on high source files)

I've attached an image to this report. There you will see that MLDonkey limits file transfer upstream perfectly to 5 KBytes per second, but total upstream is higher because of the constant peer-contacting. In my case, this meta-upstreamtraffic is 9 Kbytes/sec ! Also the return traffic of this non-filetransfer traffic is around the same magnitude. So this bug does not only waste unneccessary CPU cycles and memory but also quite a huge amount of bandwith.

Please note that I don't have a T-DSL connection, my connection is capped at hard 512'000/128'000 bits per second and it is not xDSL, so no pppoe overhead. Max upstream I've ever reached is 15.4 KBytes/sec but at about 13.5 KBytes downstream starts to collapse.

Also you can very easily see in the attached picture, that the MLDonkey GUI reports the current file transfer up/down speed which is limited very nicely to what it should and you can also see how much really is transfered in total, including the constant queries and answers of houndreds of peers.

Also you can see the quite high memory usage. It grows over time (but sometimes falls back too). Letting MLDonkey running over night in this configuration cause my Linux to kill the task in the early morning due to it eating too much memory:
Oct 30 06:11:28 linux kernel: VM: killing process screen
(mldonkey was started using screen)

Workaround: Pausing the high-source files does NOT help. It might but after 1 hr after the high-source file got paused I still had upstream exceeding connection traffic. Maybe the backlog gets too high and would settle down after a long time.

Working Workaround: Pause the high-source file(s). Kill mldonkey. Get the file-hash of the high-source files and remove them from your mldonkey temp dir. Extract the entries for those files from files.ini. Restart mldonkey without those files. Retry later when less sources exist or when bug is fixed.


Invalid User ID <#12098>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follows 1 latest change.

Date Changed by Updated Field Previous Value => Replaced by
2003-12-02 spiralvoice Open/ClosedOpen Closed

Back to the top

Powered by Savane 3.13-4b48.
Corresponding source code