Re: cvs pserver uses ALOT of memory

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Bendtsen <jbendtsen@laerdal.dk> writes:

> Den 2. mar 2004, kl. 8:28, skrev Mark D. Baushke:
> 
> > Jon Bendtsen <jbendtsen@laerdal.dk> writes:
> >
> >> Anyway, i have this problem that while checking out from my repository
> >> i get the same results.
> >> the cvs pserver ends up using 400-500 MB of memory, which is a little
> >> too much since i have about 40-50 cvs users, all using cvs throughout
> >> the day, meaning i constantly have about 4-5 users :( which fills the
> >> machine :(
> >
> > What happens when you take the largest ,v file in your repository and
> > mmap() it into memory and then add to that another full copy of the
> > checked out file to your processes memory? This is my rule-of-thumb
> > approximation for how much memory I need to have to do a proper
> > checkout
> > of the module that contains such large binary files.
> 
> allright, that explains it, the biggest ,v file is the .exe file,
> which is 369M but only 8.6M
> after a checkout.

Ahhh... yes, that would explain it.

> > Another way to approach it is to look and see how big does an RCS 'co'
> > process gets during a checking out your largest ,v file? Note that
> > checking out the top-of-tree should be easy, but checking out from a
> > branch or looking at older versions will take lots of memory.
> >
> > cvs is probably not the correct tool to use for your binary data due to
> > the way it stores deltas on a line boundary basis. You might do better
> > with subversion which uses an Xdelta method to (re)store changes much
> > more efficiently.
> 
> i know, but it's only very resently that it got to version 1.0

Indeed, but it does look like it is a very solid version 1.0...

For CVS, a possible workaround might be to change filenames for each
version of the 8.6MB file and have 'make' or something else point at the
latest version of it. This means that any given individual ,v file of
this type would only be around 9MB in the repository even though you
would hae a large number of them. You could 'cvs rm' the versions that
were no longer useful if that was determined to be needful. I would not
call this an 'ideal' solution, I merely offer it as a possible
workaround for your current situation.

        Good luck,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFARbRr3x41pRYZE/gRAj0iAKDPgoHvc9iFiHIFyyzWQJZg5RSzAQCfbve8
5GF00lnjjuJYPn1GfHuE+l8=
=0lH7
-----END PGP SIGNATURE-----