[freenet-support] changing permanent temp folder

2010-03-09 Thread Daniel Stork


Hi, I'm having problems with files stuck at 100% and having to wait hours and 
days for them to decode.
It seems that despite having all the parts freenet just sits on it for some 
reason. Is there some reason for this?
Would it be possible that you guys fix this? cuz it would be great not to have 
to wait days to decode a file that's already here.

The node.db4o file also becomes enourmous for some reason (over half Gb) after 
a few days.
It seems to be that this is what causes the files to take so long to decode, 
and it is also making the a high-end computer totally unresponsive.

In the meantime, until this hopefully gets fixed, could you tell me if there's 
a way to change the location of the persistent temp folder,
I would like to put the node.db4o on a ram disk, but the persistent temp is too 
large for this, so I would have to separate the two,
and could not find settings in freenet.ini,

Thanks a lot, and thanks for all your work on freenet, it's awsome.


  ___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe

Re: [freenet-support] changing permanent temp folder

2010-03-09 Thread Evan Daniel
On Tue, Mar 9, 2010 at 8:20 AM, Daniel Stork stork...@yahoo.com wrote:


 Hi, I'm having problems with files stuck at 100% and having to wait hours
 and days for them to decode.
 It seems that despite having all the parts freenet just sits on it for some
 reason. Is there some reason for this?
 Would it be possible that you guys fix this? cuz it would be great not to
 have to wait days to decode a file that's already here.

 The node.db4o file also becomes enourmous for some reason (over half Gb)
 after a few days.
 It seems to be that this is what causes the files to take so long to decode,
 and it is also making the a high-end computer totally unresponsive.

 In the meantime, until this hopefully gets fixed, could you tell me if
 there's a way to change the location of the persistent temp folder,
 I would like to put the node.db4o on a ram disk, but the persistent temp is
 too large for this, so I would have to separate the two,
 and could not find settings in freenet.ini,

 Thanks a lot, and thanks for all your work on freenet, it's awsome.

Hopefully this will get fixed at some point.

Could you please give us a copy of your stats page, in advanced mode?

Short term, you can remove some or all of the keys from your download
queue, and then put them back slowly, making sure the queue never gets
overly large.  (That is, save a list of things to download somewhere,
download a few, put in new ones as old ones finish.)

You could move the node.db4o elsewhere, and then add a symlink to the
new location.

Evan Daniel
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


[freenet-support] Return of the Out of memory, Part LCXIX

2010-03-09 Thread Dennis Nezic
As I (and I'm sure others) mentioned before, my node is still going
down (crashing?) regularly -- roughly weekly. I currently allocate it
150MB of (precious) ram. Here are my last 2 (of infinity) heap reports
from the jvm dump:

Heap
 def new generation   total 46080K, used 41323K 
  eden space 40960K, 100% used 
  from space 5120K,   7% used 
  to   space 5120K,   0% used 
 tenured generation   total 102400K, used 99586K 
   the space 102400K,  97% used 
 compacting perm gen  total 12288K, used 11390K 
   the space 12288K,  92% used 
ro space 10240K,  61% used 
rw space 12288K,  60% used 

Heap
 def new generation   total 46080K, used 41400K 
  eden space 40960K, 100% used 
  from space 5120K,   8% used 
  to   space 5120K,   0% used 
 tenured generation   total 102400K, used 102399K 
   the space 102400K,  99% used 
 compacting perm gen  total 12288K, used 11214K 
   the space 12288K,  91% used 
ro space 10240K,  61% used 
rw space 12288K,  60% used 

Is there NO way that freenet can do a better job cleaning up? (I
believe this happens even if I don't have (much) currently in the queues
-- Ie. if I did heavy activity days before -- or maybe even on it's own
without any manually-initiated activity, although I would have to test
this more :\.)

Maybe we can add more debugging info as to where all the memory is
allocated? Ie. which structures? (And hopefully decide that we can Let
Go of some of them :|.)
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


Re: [freenet-support] Return of the Out of memory, Part LCXIX

2010-03-09 Thread Evan Daniel
On Tue, Mar 9, 2010 at 3:34 PM, Dennis Nezic denn...@dennisn.dyndns.org wrote:
 As I (and I'm sure others) mentioned before, my node is still going
 down (crashing?) regularly -- roughly weekly. I currently allocate it
 150MB of (precious) ram. Here are my last 2 (of infinity) heap reports
 from the jvm dump:

 Heap
  def new generation   total 46080K, used 41323K
  eden space 40960K, 100% used
  from space 5120K,   7% used
  to   space 5120K,   0% used
  tenured generation   total 102400K, used 99586K
   the space 102400K,  97% used
  compacting perm gen  total 12288K, used 11390K
   the space 12288K,  92% used
    ro space 10240K,  61% used
    rw space 12288K,  60% used

 Heap
  def new generation   total 46080K, used 41400K
  eden space 40960K, 100% used
  from space 5120K,   8% used
  to   space 5120K,   0% used
  tenured generation   total 102400K, used 102399K
   the space 102400K,  99% used
  compacting perm gen  total 12288K, used 11214K
   the space 12288K,  91% used
    ro space 10240K,  61% used
    rw space 12288K,  60% used

 Is there NO way that freenet can do a better job cleaning up? (I
 believe this happens even if I don't have (much) currently in the queues
 -- Ie. if I did heavy activity days before -- or maybe even on it's own
 without any manually-initiated activity, although I would have to test
 this more :\.)

 Maybe we can add more debugging info as to where all the memory is
 allocated? Ie. which structures? (And hopefully decide that we can Let
 Go of some of them :|.)

What plugins are you running (complete list)?  Can you provide a copy
of your full stats page, in advanced mode?

Evan Daniel
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe