[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: massive memory leak

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Tue, 19 Oct 2010 18:41:55 +0200

On 19.10.2010 18:38, Philip Martin wrote:
> Stefan Küng<tortoisesvn_at_gmail.com> writes:
>
>> I'm still using r1023755 from trunk, but I haven't seen a commit which
>> I think would fix this:
>>
>> There's a massive memory leak somewhere. I can't check out even small
>> projects anymore since the memory consumption raises very fast and
>> reaches the limit of my available RAM (6GB) after about the first 100
>> files. After that, the system isn't usable anymore because the
>> constant swapping.
>>
>> I then tried an update of the interrupted checkout (had to hard reset
>> the system because it wasn't reacting anymore), but the update too
>> uses up all memory in a few seconds.
>>
>> Switching to neon instead of the default serf fixes the problem. So
>> this is limited to either serf itself or ra_serf.
>> I'm using serf 0.7.0
>
> On my Linux machine I can checkout Subversion trunk using serf and the
> memory used by the process (as reported by top) is about 150MB. Neon
> uses slightly less memory, about 130MB. I'm using Subversion r1024287,
> serf 0.7.0, and apr 1.2.12.
>
> Does the problem occur with one big file? A hundred small files in
> one directory? A hundred nested directories with no files? With
> http-compression? Over https?

I tried to check out npp:
https://notepad-plus.svn.sourceforge.net/svnroot/notepad-plus/trunk

Nothing special about file sizes or number of files.

I'm using:
Windows 7 x64
sert 0.7.0, apr 1.3.8, apr-util 1.3.9

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
Received on 2010-10-19 18:42:40 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.