out of memory; can not reallocate

Hi guys,

I am testing moving a cvsnt server from linux to windows.
The linux server 
was cvsnt2.5.02.2099 on redhat ES3 and the windows box is 
cvsnt2.5.03.2382. We have a particular module that is
relatively big (1.7 
GB, 17574 files) and I get an error on checkout that says:

cvs [server aborted]: out of memory; can not reallocate
322961408 bytes

This happens on the windows server and not on the linux
server. I've read 
about the RAM requirements and such that people run into,
but the linux 
server has 4 gigs of ram and 8 gigs of swap and the windows
server is a VM 
with 3.6 gigs of RAM and 7.5 Gigs of swap. Without assuming
that the 
slight difference in RAM is the problem, can anyone else
tell me what 
MIGHT be the problem?

Thanks!

Brian
_______________________________________________
cvsnt mailing list
cvsntcvsnt.org
h
ttp://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt

> From: cvsnt-bouncescvsnt.org 
> [mailto:cvsnt-bouncescvsnt.org] On Behalf Of
bwhicksaep.com
> Sent: Friday, 09 February, 2007 13:35
> 
> I am testing moving a cvsnt server from linux to
windows. The linux
server 
> was cvsnt2.5.02.2099 on redhat ES3 and the windows box
is 
> cvsnt2.5.03.2382. We have a particular module that is
relatively big
(1.7 
> GB, 17574 files) and I get an error on checkout that
says:
> 
> cvs [server aborted]: out of memory; can not reallocate
322961408
bytes
> 
> This happens on the windows server and not on the linux
server. I've
read 
> about the RAM requirements and such that people run
into, but the
linux 
> server has 4 gigs of ram and 8 gigs of swap and the
windows server is
a VM 
> with 3.6 gigs of RAM and 7.5 Gigs of swap.

Forget RAM; the whole point of a paged-virtual-memory
operating system
is that processes aren't constrained by physical memory.

We can't evaluate whether swap space is a problem without
knowing the
total demand on virtual memory on the server, but it's very
unlikely.

The important differences are in the C runtimes, which are
completely
different implementations (presumably glibc of some vintage
on Linux,
MSVC 7.1 on Windows), and therefore may have different
implementation-defined behaviors; and the OSes, from which
the C runtime
must request memory, and which are radically different.

The realloc C library function can satisfy a reallocation
request in two
ways: it can extend the existing area; or it can allocate a
new area and
copy the data from the old area, then free the old one. 
Whether
extending an area is possible depends on a host of factors,
but C
library implementation and OS figure prominently.  So it may
well be
that on Linux, CVS is able to resize the area, but on
Windows it needs
to allocate fresh and copy, which means it might actually
need
considerably more than the amount it's trying to allocate,
at least
ephemerally.

322961408 bytes is about 308 MB, which is a sizable chunk of
available
address space in a 32-bit process model.  32-bit Windows
reserves big
portions of the process address space for stack, shared
libraries, etc.
That leaves only so much for the heap (where
dynamically-allocated
memory comes from); at the point where this reallocation
request occurs,
there may simply not be 308 MB of address space left for the
heap to
grow into.

I've never had to alleviate heap-space exhaustion for a
Windows
application, so I'm not sure what your options are here. 
(Other than
not putting 308 MB files into CVS, of course - and it's
probably rather
too late for that.)  But maybe these suggestions will help
you research
possible solutions.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus
_______________________________________________
cvsnt mailing list
cvsntcvsnt.org
h
ttp://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt