Quote:
Originally posted by Unregistered
Greetings all,
An hour ago, before a reboot, LimeWire had been up long enough to become an ultrapeer, and I had 200 some processes. Right now, after the top was run, ps reveals that there are 50 sleeping java processes consuming my memory--more than 100% of it, if top is to be believed. BTW, right now I'm only serving as a leaf node.
I'm not sure if this is a LimeWire or JRE issue, but LimeWire is the only java program I've run yet on this system, so I haven't checked to see if others would behave the same way. Also, a quick check of the JRE forum at Sun didn't reveal any threads related to this issue.
So, what can I do? Is this situation abnormal? I've gone through the LimeWire options to try and reduce the load, but the only thing appropriate I could find (besides the "don't serve as ultrapeer" box) was the freeloader bar, which is already set at "rarely".
|
That's rather an issue of reading the ps/top output. First of all, each Java thread in your ps-output shows the memory, the whole JavaVM uses up. ps is unable to show the memory usage of a single thread. So if a java thread is using up 60000k or something, that will mean that the whole JavaVM is using that memory and not the single thread.
Top will never show your memory empty or even nearly empty, by the way, since linux is using "free" memory for the purpose of caching.
You also don't have to reboot your computer. "killall java" usually just works fine, although your computer may have a hard time reacting, if your cpu time is really used up.
The number of threads (and thus also memory usage) is currently still a problem LimeWire has, - LimeWire needs two threads per connection, so if you are an Ultrapeer with up to 81 connections, you easily hit the bottom line. However I know, the LimeWire developers are working on that issue. This will take some time, they will have to restructure the way LimeWire handles the connections completely. LimeWire was initially not designed to handle such a number of connections.