info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: memory exhausted


From: Alex Krasnov
Subject: Re: memory exhausted
Date: Thu, 13 Nov 2008 18:36:33 -0800 (PST)

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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]