Higher CPU usage.BT related?Is this normal?

[spongebob]

hey guys!

i'm also experiencing high cpu consumption on my 1.2ghz athlon with 512 mb ram, of which mld eats 1/2 currently after 54 days uptime.
however unlike some of you, i cannot see any wait state of the cpu, it's all eaten by user processes.

after reading this thread here, i tried disabling the bt plugin (without restart of mldonkey), but this did not change the fact, that mldonkey likes to use 99% of my cpu quite often (load average: 0.72, 0.66, 0.57).

before i try restarting, cleaning configs or anything, i'd like to ask what things i should do, to help your ongoing investigations.
i have lots of free time on my hands currently and am willing to try some stuff to resolve this problem!

[fabtar]

Hi spongebob
I'm not a developer but I think you could try two things( I suggest to do these experients in this order):
IMHO
Experiment 1:
1) compile your core with profiling as mentioned above.Your situation is interesting cause it seems your CPU problme is always triggered.

Start your donkey for few days and post here your profile results.

Experiment 2:
2) Eliminate GeoIP database usage and restart mldonkey (eliminate webinfos about and your LOcal GeoIP.dat located in .mldonkey abysses).

After a resonable time: Is your mlnet performing better ? (yes/no/Don't know)

Experiment 3:
Mantain the same directory structure, same eshared files folder, simply start mldonkey anew with config files FROM SCRATCH..no files.ini.. nothing ...
The best thing is to do this with an empty download list (I have noted that recovering the old downloads from temp is sometimes long and hard and heavy for mlnet), so , I suggest to not recover your old /temp but to delete your pending downloads.

Prhaps you can obtain same effect by launching anew mldonkey using another user and simply using another temp directory but same shared and incoming folder.

Is the fresh mldonkey performing better (with new donwloads)?

I think this is useful to track problems related to corrupted ini files.

/IMHO

[spiralvoice]

Selected IRC log from February 3th, 2007:

[spiralvoice]

Some more backgrounds about compaction_overhead:
http://mldonkey.sourceforge.net/forums/viewtopic.php?p=12275#12275
_________________
Link overview and precompiled cores here: http://mldonkey.sourceforge.net/DownloadLinks

[spiralvoice]

compaction_overhead = 500 is too high here, after ~ 5 minutes
MLDonkey used 120MB RAM instead of the normal 50MB.

Then I set compaction_overhead = 200, RAM usage raises
to around 75MB, then a GC is running (up- /download stops
for a second) and it goes back to 50MB, which is ok.
Current DL speed 82 kb/s, UL 28 kb/s (reported by Sancho).

Machine has 256MB RAM, AMD K6 300 MHz.

Each GC leaves a small hole in the upload statistic:

Ini file saving does not produce any holes in the stats with ED2K-keep_sources = false.
_________________
Link overview and precompiled cores here: http://mldonkey.sourceforge.net/DownloadLinks

[spongebob]

I had to restart my machine 2 days ago (kernel update). After the restart, the problem with the high CPU usage is gone. I did not remove any downloads or change ini files. Also the memory usage dropped from about 290 MB after 54 days uptime to initial 50 MB. Now after 2 days of operation and several completed downloads (also from BT), mldonkey currently uses 67 MB.
During these 2 day I've been checking the memory and CPU usage from time to time, and there were no abnormalities.

I have now set compaction_overhead to pango's proposed value of 500. Just out of curiosity

[update]
After some hours with the new compaction_overhead value, the memory usage is stable around 75 MB. The CPU usage has not increased. From the webgui statistics graph I can however not see clearly if there occur the same "holes" during GC - there is currently to much turbulence. I'll keep an eye on it.