leaks, leaks, leaks

Last weekend we had a gigantic 'svn import' leak, and our wonderful
developers found the bug and nailed it.

Now we have a whole gaggle of leaks -- maybe related, maybe not. Pick a
leak, any leak.

I've been testing r7433 today, looking for more memory scalability problems
on "large trees" (45K files, 340M), using the same old Mozilla source tree.
I've only been testing ra_dav operations.

The good news: for every operation, the httpd processes show no growth at
all. They all hover at a steady size, somewhere between 7 and 12M. Also,
the 'svn import' of the Mozilla tree is totally fixed. The client stays at
a tiny 7M the whole time.

The bad news is the results of every other basic operation:

* 'svn co' of mozilla tree

    svn client starts at 5M, slowly grows to 40M over 35 mins.

* 'svn up' -- empty update (no changes)

    client grows from 5M to 40M over 5 mins.

* 'svn status' -- local status, no changes in the tree.

   client grows to 40M over about 2 minutes, then hovers there for 10
   more minutes before finishing (!!!)

* commit a small changeset **CLIENT LEAK**

  edit two files deep in the tree, then commit.
  client grows to 40M over 5 mins, then hovers there for 9 more minutes.

* 'svn up' -- nonempty update to a different wc

  client grows to 40M, takes 14 minutes to finish.

So what's up with this magical 40 meg client size? It shows up in
every command -- checkout, update, status, commit!

Is it the size of 5000 entries files loaded into memory -- about
42,000 individual entry structures?

Any ideas?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 17 23:06:25 2003