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

Re: git-repack keeps running out of memory

From
PSPhil Susi <psusi@ubuntu.com>
Date
Jun 1, 2015, 19:07 UTC
Message-ID
<556CAD64.8000208@ubuntu.com>
In-Reply-To
<xmqqlhg35ky2.fsf@gitster.dls.corp.google.com>
On 6/1/2015 2:43 PM, Junio C Hamano wrote:
Show 20 quoted lines
> Phil Susi <psusi@ubuntu.com> writes:
>
>> I keep having git-repack run out of virtual memory ( 32 bit system )
>> when trying to repack my linux kernel repo.  It keeps making it right
>> up to 99% then barfing saying mmap failed: Cannot allocate memory.
>>
>> I thought I could help this by limiting the pack size, and using
>> --window-memory to limit the memory usage, but it still happens with
>> this full command line:
>>
>> git repack -a -d --max-pack-size=500m -f -F --depth=20 --window=250
>> --window-memory=500m
>>
>> The key factor seems to be the --window... with 50 it works fine, but
>> with 100 or more, even with the very low --window-memory limit, it
>> crashes.
>
> Unfortunately, that is totally expected.  Window tells us to keep
> enough information to compare with that many objects in-core.  I do
> not think max-pack-size would affect much.

It's more the --window-memory argument that is important here: it is supposed to prevent exactly this problem. I guess I tried adding the --max-pack-size as well on the off chance that it would help.

Previous: Junio C HamanoNext: Jeff King
Message 3 of 5 in “git-repack keeps running out of memory”
  1. Phil SusiJun 1, 2015
  2. Junio C HamanoJun 1, 2015
  3. Phil SusiJun 1, 2015
  4. Jeff KingJun 1, 2015
  5. Phillip SusiJun 2, 2015

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.