I suspect the stalled downloads are the same problem as the heavy IO,
and that both come from the downloads database.  I would expect
increasing the memory available to help; I'm somewhat surprised it
doesn't.  I doubt there's much io to the datastore in comparison.  If
you want to play with ram disks, putting the data store on a normal
hard disk and the node.db4o (or node.db4o.crypt) file on a ram disk is
more likely to help.  However, first I would try defragmenting your
node.db4o file (configuration -> core settings -> Defragment the
downloads database during the next startup? -> true).  Does setting
that and then restarting the node help?  How big was your node.db4o
file before / after defragmenting?

If none of this helps, then I suspect you simply have more downloads
queued than Freenet can handle.  I recommend removing some or all of
the files, and then re-adding them when others finish, keeping the
total size queued at any one time limited.

Evan Daniel

On Sat, Mar 6, 2010 at 10:03 AM, Daniel Stork <stork...@yahoo.com> wrote:
> Evan, thanks for the response, I tried playing around with the memory, and
> giving freenet 2 gb makes it crash,
> but it works with 1,5gb (I have a total of 4gb installed).
> The memory did not change anything. The disk was churning a lot so I
> transferred the datastore to a 2gb ramdisk, which reduced some of it.
> But still the system becomes really unresponsive, when using freenet.
> Any ideas what this could be? All my hardware is really more than enough, I
> have one of the best Core 2 Duos and all resources are underutilized.
> Also, - I know others have asked already, but am not sure if this issue was
> ever resolved - I have numerous downloads at 100% that do not complete.
> I have been waiting for hours and days.
> Any idea why this happens?
> I usually have about 80-100 simultaneous downloads, is this too much for
> freenet to handle?
> Thanks a lot,
> ________________________________
> From: Evan Daniel <eva...@gmail.com>
> To: support@freenetproject.org; Daniel Stork <stork...@yahoo.com>
> Sent: Mon, January 25, 2010 7:13:43 PM
> Subject: Re: [freenet-support] major problems - stuck at 100%, nonresponsive
> On Wed, Jan 20, 2010 at 6:26 PM, Daniel Stork <stork...@yahoo.com> wrote:
>> Hi,
>> I'm having major problems with freenet on Windows, I have 60 downloads of
>> which 60 have been stuck at 100% for days.
>> Running freenet makes Windows completely unresponsive.
>> It takes literally 10 minutes for frost to start up.
>> This happened in the past. I deleted node.db4o and the permanent downloads
>> folder and this fixed it for a while,
>> But it goes back to the same state in a few days.
>> Right now my node.db4o is 230 Mb and I don't want to lost the 60 downloads
>> (almost 10 gigs total) which are complete.
>> The CPU usage is 50-80% on a very strong pc.
>> My questions are the following:
>> 1. Could the unresponsiveness be a memory issue with Java ? I have 4 gigs
>> but  freenet and frost use only 160 and 210 megabytes. Is java putting  a
>> limit on these somehow?
>> What's the proper way to allocate memory to freenet and frost ?
> Freenet has a configuration option.  You can set it from configuration
> -> core settings -> max memory.
> For frost, run it with "java -Xmx256M -jar frost.jar" (or whatever
> setting you prefer) instead of the normal "java -jar frost.jar".
> It's possible your issue is Freenet memory; I'm not certain.  Please
> let me know if increasing memory available helps.
>> 2. Does setting priority in task manager have any effect ? I noticed they
>> are on "below normal" and cannot be changed.
> I'm not certain.  Freenet normally runs most of its threads at very
> low priority, and a couple at higher priority.  Reducing the priority
> too far on some OSes can mean the high priority threads get starved
> for CPU, causing timeouts and restarts and such.  I'm not sure if this
> happens on windows.
>> 3. Is there a way to save these completed downloads that freenet is not
>> finishing (i.e. command line utility)?
> Just the normal download process.  Reducing the size of your queue
> will fix the problem, and increasing the memory available may help.
>> Also another issue I noticed:
>> - When I select "Download the file in the background and store in
>> R:\Freenet\downloads" or "Fetch the file in the background" from the
>> freenet
>> UI,
>> it doesn't do anything. Are these supposed to work?
> They should add the file to your download queue; they work fine here.
> What does happen?  What error message are you getting?
> Evan Daniel
Support mailing list
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe

Reply via email to