[tahoe-dev] [tahoe-lafs] #783: long running tahoe process - appears to be a slow memory leak
tahoe-lafs
trac at allmydata.org
Sat Aug 8 08:41:53 PDT 2009
#783: long running tahoe process - appears to be a slow memory leak
----------------------+-----------------------------------------------------
Reporter: terrell | Owner: somebody
Type: defect | Status: new
Priority: critical | Milestone: undecided
Component: code | Version: 1.5.0
Keywords: leak | Launchpad_bug:
----------------------+-----------------------------------------------------
Changes (by zooko):
* priority: major => critical
Comment:
I'm elevating the priority to "critical" because a big memory leak like
this could prevent Tahoe-LAFS from being used in some cases. By the way,
we've always been careful about this. We have graphs of the virtual
memory usage of short-running programs which get automatically generated
on darcs commit:
http://allmydata.org/trac/tahoe/wiki/Performance
And allmydata.com has graphs of the virtual and resident memory of long-
running storage server processes. Unfortunately those graphs aren't
public. I'll ask Peter Secor if we could make the live view on those
graphs public. I'll attach the graphs from one of those servers to this
ticket.
So, it is interesting that Trel's is the first report of something like
this. I've been running long-running Tahoe-LAFS on my Intel Mac 10.4, and
I've never seen something like this.
Note: we *have* seen major memory problems, but never a long-running slow
memory leak like this, only a catastrophic "Out Of Memory -- now I am
totally confused and broken" -- #651. Trel: please look in your
{{{twistd.log}}} for {{{MemoryError}}}.
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/783#comment:5>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list