You should really send these to the support list; that's what it's for.

You can change the physical security level setting independently of
the network seclevels -- see configuration -> security levels.

I'm not sure what else to suggest at this point.  You could try
increasing the amount of ram for temp buckets (configuration -> core
settings), but that's mostly a stab in the dark.

I suspect you need to reduce the amount of stuff in your queue.

Evan Daniel

On Mon, Mar 8, 2010 at 8:05 AM, Daniel Stork <> wrote:
> Defragmenting the database did help. It went from 520 Mb to 160 Mb,
> This made it a bit more responsive and the smaller files now finished in
> about an hour,
> but the larger ones are still stuck at 100%.
> Could you tell me how to change the location of the persistent temp folder?
> I didn't see this in freenet.ini
> I'd like to put to node.db4o.crypt file on the ramdisk, but the persistent
> temp is way too big for that.
> Does the node.db4o have to be in the same folder as the persistent temp ?
> Also, if I'm running freenet from either a ramdisk or a truecrypt volume,
> than does it make sense to have the persistent temp and the datastore and
> db4o encrypted ?
> Is it possible to just have these unencrypted without affecting my online
> security settings ?
> Thanks a lot,
> Dan
> ________________________________
> From: Evan Daniel <>
> To: Daniel Stork <>;
> Sent: Sat, March 6, 2010 4:38:23 PM
> Subject: Re: [freenet-support] major problems - stuck at 100%, nonresponsive
> 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 <> 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 <>
>> To:; Daniel Stork <>
>> 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 <> 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

Reply via email to