mldonkey-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mldonkey-users] Re: mldonkey eating up all memory again


From: René Gallati
Subject: Re: [Mldonkey-users] Re: mldonkey eating up all memory again
Date: Thu, 21 Nov 2002 13:53:41 +0100

Hi list,

>> I just tried the patches without any success. mldonkey still crashes
>> with the "out of memory" message.  i will try the latest cvs version
>> of ocaml to see if it helps in any way.

Little note: mldonkey does NOT crash, your VM (kernel) kills the process
because of too high memory usage.

>Then there must be something very special about Debian unstable, as I am
>able to run my mldonkey on a K6-2/450 with 128MB RAM w/o _any_ problems.
>It uses about 22MB RAM and some 5% CPU. But: I only have 185 files to
>download with 41 active, the rest paused, sharing now 46GB of files
>(this are about 2000 files).
>I use exactly the same DEBs of what I have made availible on the web.

As I already wrote on this list and also made a comprehensive bug report
(Bug 1555 see here
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=1555&group_id=1409 )

the memory (and CPU and bandwith) eating behaviour on mldonkey ONLY appears
if you have a high-source file in your download list. A high-source file is
a file, where several houndreds of peers for that file are known.

You can - of course - also add more ram to your machine which mitigates the
problem (at least in respect to memory) somewhat. Also setting the
compaction_delay parameter down to 1 hr forces mldonkey to free that unused
memory it keeps locked sooner, thus also helping a bit.

However it IS a bug in mldonkey, no matter what people are saying who can't
reproduce it, and unless it is fixed, consider cancelling all files in your
mldonkey which are high-source and then restart mldonkey. At least it wont
drive your box into the constantly swapping mode.

Note CVS version 2.00+2 is *slightly* better but has the same problem. It is
less "greedy" thus it asks those sources less "fast" and eats less memory,
bandwith and cpu but it still suffers from the very same bug.
--

C U

     - -- ---- ----- -----/\/  René Gallati  \/\---- ----- --- -- -







reply via email to

[Prev in Thread] Current Thread [Next in Thread]