Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[etatoby]

Hi guys

I'm having a problem: aMule goes 100% CPU as soon as I try to connect to a server.

This means that the interface hangs—apparently forever—and I can't do anything except clicking on the [×] window button and wait several minutes fot it to shut down. That or killing it. :]

I have found the following piece of documentation: «If you share more than ~200 files […] you may be kicked from [many servers.] Consider not to share that many files.» I don't know if the 200 figure is a mistake or what. I am sharing more or less 20k files and actually aMule used to be snappy until I put them in my shared list. So this is my best guess for the slowliness right now. BUT!

1. 20k files is not much, I routinely share them in many other networks (DC, Gnutella…) What's the point of sharing fewer files than you have anyway? (Note: they are all useful, commonly shared files. No 1k bullshit.)

2. The documentation doesn't talk of aMule being slow if you share too many files, only of servers kicking you. I don't understand the reason for this kind of kickage, but I could cope with that, trying other servers and such… if only aMule didn't hang!

3. The shared files are already well hashed (it took quite some time, of course) so I don't see a reason for aMule being so slow. I could understand if it hogged the upload bandwidth, trying to transfer the list of files to some server in a non-optimized way (I don't even know if aMule's protocol does that) but the upload bandwidth stays zero! The CPU is the only resource affected.

4. It's not a filesystem issue either. "find /path/shared -type f" takes a few seconds the first time and a fraction of a second afterwards. aMule's full hashing took a couple of hours. This new thing has been going on for much more.


Any developer reading this? Did somebody put some stupid piece of code, non-linear on the number of files, somewhere? I don't think I'm the first user trying to share a decent amount of stuff. But I can debug and such so feel free to ask me for developer stuff. Should I try the CVS version?

For now I am going to try and let it have plenty of CPU for a whole day, hoping this is a one-time only thing. Any other advice would be appreciated.

[stefanero]

yeah, some developers stop by from time to time and read posts from users

what version of amule are you using? rc8 or which one?

but since we are preparing for 2.0 final, try amule-cvs from http://amule.hirnriss.net
if there is a bug we should find it there, and not in the old rc8 build.

btw: how many files do you share? I mean the actuall number!
in the beginning amule might be slow because if those files are new on your shared files list, amule hast to rehash every single one of them!
in the end they will endup all in your shared-files tab in amule, so you can check how many amule has already hashed and how many are still to go
so while its rehashing the response of the gui when connecting to the server might be not be really good.

stefanero

[etatoby]

I guess my rant above was a bit too verbose. Here's an abstract.


I'm using 2.0.0rc7, as for thread title. I will try CVS ASAP.

The files are all already hashed, the hashing took an average amount of time.

As I said before I have approx. 20.000 files of average size (mostly 2…7MB, a few 700MB), all already hashed.

12 hours ago I started the program. As soon as I clicked Connect, it went to 100% CPU and the GUI stopped responding. 12 hours later It is still at 100%.


Any suggestion?

[stefanero]

well no suggestions atm, try cvs....
its been long time since rc7....and really a huge amount of bugs has been fixed, altho I doubt a server will let you share 20000 files...but I guesss you'll find out