git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: running out of memory when doing a clone of a large repository?

From
Nicolas Pitre <nico@cam.org>
Date
Nov 13, 2008, 03:22 UTC
Message-ID
<alpine.LFD.2.00.0811122206550.27509@xanadu.home>
In-Reply-To
<491B2550.1050005@cs.cmu.edu>
On Wed, 12 Nov 2008, Paul E. Rybski wrote:
Show 26 quoted lines
> Hi,
> 	I've recently started evaluating git for use on one of my projects.  I
> used git-svn to convert a fairly large subversion repository and one of
> its branches into two separate git repositories following the
> instructions found here:
> 
> http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/
> 
> From that, I created a 1.5G repository from the trunk of the subversion
> repo and a 1.1G repository from one of the branches.  I then tried to
> clone the repositories from one machine to another via ssh and the
> smaller 1.1G repository of the subversion branch (with 1932 commits)
> came over just fine but the larger 1.5G repository of the subversion
> trunk (5865 commits) died with the following error:
> 
> remote: Counting objects: 48415, done.
> remote: warning: suboptimal pack - out of memory
> error: git-upload-pack: git-pack-objects died with error.
> fatal: git-upload-pack: aborting due to possible repository corruption
> on the remote side.
> remote: aborting due to possible repository corruption on the remote side.
> fatal: early EOF
> fatal: index-pack failed
> 
> Is this simply because the git repository is too large for the machine
> that's trying to send it over ssh?
Possibly.
> Is there a way to restrict the memory usage of git or do I need to get 
> more RAM or somehow not import the full subversion history of my 
> original trunk?

It is possible that the inport from svn didn't produce a fully packed repository. Try a "git repack -a -f -d" on the server machine. If you get the same out-of-memory problem then ideally you should copy the whole directory to a bigger machine and run 'git repack -a -f -d" there. Then you may copy it back to the small machine and subsequent clone requests should be just fine.

You could also investigate the pack.windowMemory configuration variable on the server side. If you have lots of big files then setting this to 64m for example may help.

> I'm using Ubuntu 8.04.1 on both machines and using the Ubuntu packages
> of git version 1.5.4.3.

There was a bug in versions prior to v1.5.6.4 affecting memory usage. Upgrading to this version or later on the server machine might help too.

Show 21 quoted lines
> The machine holding the repository is a 5-year
> old AthlonXP 3200 with 1G RAM and 32-bit Ubuntu.  The machine I'm
> cloning the repository on is a more recent Intel Dual Core Quad Q6600
> with 4GRAM and 64-bit Ubuntu.
> 
> Any advice would be greatly appreciated.
> 
> Thanks!
> 
> -Paul
> 
> -- 
> Paul E. Rybski, Ph.D., Systems Scientist
> The Robotics Institute, Carnegie Mellon University
> Phone: 412-268-7417, Fax: 412-268-7350
> Web: http://www.cs.cmu.edu/~prybski
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
Nicolas
Previous: Paul E. RybskiNext: Paul E. Rybski
Message 2 of 3 in “running out of memory when doing a clone of a large repository?”
  1. Paul E. RybskiNov 12, 2008
  2. Nicolas PitreNov 13, 2008
  3. Paul E. RybskiNov 13, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.