Re: memory exhausted

I am reasonably certain that the problem is on the server, although the 
local method does not trigger it. On the other hand, the local method 
seems to use different memory allocation method.

More significantly, downgrading to CVS 1.11.22 on the server appears to 
have eliminated the problem. The server CVS process now grows to over 1.2 
GB of resident memory but does not fail for the 360 MB file, since this 
version appears to not use mmap. Thanks for this suggestion--I did not 
realize that the version that I was using is the unstable feature release.

Alex


On Thu, 13 Nov 2008, Paul Sander wrote:

>
> On Nov 13, 2008, at 4:00 PM, Todd Denniston wrote:
>
>> Paul Sander wrote, On 11/13/2008 05:28 PM:
>>> I found the mmap in CVS 1.11.23, and would not be at all surprised to find 
>>> it also in the unstable release that Alex is using.  I'm certain it's been 
>>> in CVS since CVS absorbed RCS.
>> 
>> I don't think it has been quite that long, at least on solaris.
>> http://lists.gnu.org/archive/html/bug-cvs/2003-11/msg00152.html
>> 
>> mmap happened between 1.11.1p1 and 1.11.2.
>> the solaris mmap patches I applied for solaris 2.6 did not help.
>> 
>> At least in the 1.11.x series you could drop mmap by:
>> after you configure (but before compile) of cvs Version >1.11.1p1  make the
>> following change in config.h:
>> 
>> diff config.h.normal config.h
>> 199c199
>> < #define HAVE_MMAP 1
>> ---
>>> /*#define HAVE_MMAP 1*/
>> 
>> then `make; make install`
>> 
>> and if you felt like it, you could follow some of my other suggestions 
>> about having mmap problems :)
>> http://lists.gnu.org/archive/html/info-cvs/2003-12/msg00300.html
>
> Keep in mind that with mmap turned off, CVS reads the RCS file into a malloc 
> buffer that gets realloc'ed as it overflows.  Under conditions where the 
> entire RCS file is read, which is just about anything that reads beyond the 
> initial admin section (including every commit and tag operation, and most log 
> operations), this can be inefficient and cause a swap space overflow even if 
> much of the heap is unused.
>
> If I recall correctly, RCS had a large-memory non-mmap option that would stat 
> the RCS file and allocate a single buffer large enough to accommodate it, and 
> read it all in at once.  This was in addition to the slower small-memory 
> method that never read the entire RCS file into memory.  It would be nice if 
> CVS incorporated these capabilities, too.  A bonus would be to fall back to 
> the small memory method if it anticipates a shortage of memory based on 
> current consumption and system limits.
>
>