[prev in list] [next in list] [prev in thread] [next in thread]
List: subversion-issues
Subject: [Issue 622] Changed - Memory used during a checkout
From: issues () subversion ! tigris ! org
Date: 2002-05-28 19:34:33
[Download RAW message or body]
http://subversion.tigris.org/issues/show_bug.cgi?id=622
*** shadow/issues_15/622 Mon May 20 20:05:56 2002
--- shadow/issues_15/622.tmp.27283 Tue May 28 12:34:33 2002
***************
*** 2,9 ****
| Memory used during a checkout |
+----------------------------------------------------------------------------+
| Issue #: 622 Component: subversion |
! | Status: STARTED Version: current |
! | Resolution: Platform: All |
| Issue type: DEFECT OS/Version: All |
| Priority: P2 Subcomponent: src |
+----------------------------------------------------------------------------+
--- 2,9 ----
| Memory used during a checkout |
+----------------------------------------------------------------------------+
| Issue #: 622 Component: subversion |
! | Status: RESOLVED Version: current |
! | Resolution: FIXED Platform: All |
| Issue type: DEFECT OS/Version: All |
| Priority: P2 Subcomponent: src |
+----------------------------------------------------------------------------+
***************
*** 63,65 ****
--- 63,85 ----
milestone. It's an issue with apr pools not re-using memory.
Sander and I are going to be reviewing pool patches this week.
+
+
+ ------- Additional Comments From sussman@tigris.org 2002-05-28 12:34 -------
+ OK, here's the final deal on this situation.
+
+ As Kirby pointed out, the memory consumed during checkout *was*
+ proportional to the number of files received (at least, over
+ ra_local.) This is because apr's pools never, ever free or re-use
+ memory; memory usage can only grow until the main process exits.
+
+ At least, that's how pools used to be. Sander has changed the pools
+ implementation so that memory is now being re-used, and so that the
+ global 'free list' of available pool memory is never greater than 4 megs.
+
+ If you update subevrsion to r2017 (and update apr as well), checkouts
+ and filesystem dumps are now much more reasonable. They tend to grow
+ to a certain size (somewhere between 12 and 19 megs) and then
+ "stabilize" for the remainder of the operation (as memory is re-used.)
+
+ Closing this issue.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic