[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