[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Reproduceable failure

From: Julia Wolf
Subject: Re: [GNUnet-developers] Reproduceable failure
Date: Tue, 1 Apr 2003 19:42:22 -0500 (EST)

On Mon, 31 Mar 2003, Krista Bennett wrote:

> Igor Wronsky hath spoken thusly on Mon, Mar 31, 2003 at 08:30:26PM +0300:
> > I've been tolerating this ultimate mem hogging for over a month
> > now and my patience with the involved parties, including
> > myself, is growing thin.
> I think I vaguely recall him not being able to reproduce the mem-hogging
> situation, although I could be mistaken.

  I've been using 0.5.2 and 0.5.2a for the last month or so, and I've also
seen the gnunetd proccess steadilly using up more and more memory until
Linux kills the proccess. I added some extra swap space, and the gnunetd
proccess got all the way up to over 700M of memory. I think this was
happening with both 'gdb' and 'directory' for afs. It also seems to only
occur when gnunetd is talking to the rest of the network. When I leave it
'offline' then it doesn't take up more than 20M or so.. (I also switched
to using 'mysql' but I don't think that's related)

  I havn't started to try to track the memory leak down yet...

  Perhaps unrelated, and not to be unexpected, if you use 'directory' for
afs, and insert a few gigs of content, the CPU load goes up to a constant
load or 2.5 (in my case) at which point gnunetd starts dropping stuff as
per the setting in gnunet.conf . Consequently you can't actually use
gnunet anymore, because gnunetd itself is eating up all the cpu time and
starving everything else. (I mean it'll just sit there and thrash at the
drive) 'gdb' and 'mysql' don't have this problem. (I'm guessing all the
disk thrashing happens every time there's a hash lookup) (oh and the
direcotry was sitting on a reiserfs filesystem)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]