Anders Kaseorg writes ("Re: Bug#841414: git "fatal: Out of memory? mmap failed:
Cannot allocate memory""):
> Git really is running out of memory. When I try this locally (using
> file:// to force Git to go through the same git-upload-pack dance that it
> does over a smart transport, and using ulimit -v as a poor but probably
> sufficient approximation of a RAM-limited server), it fails with 920 MB of
> virtual memory and succeeds with 940 MB:
Thanks for the investigation. You have provided useful facts.
So I think in terms of the questions I asked, you are saying:
* This is not a very unusual level of memory usage[1] so the server
should be provisioned with more swap, at the very least, and
probably more RAM.
* Using git-gc more often might be beneficial.
Many (most?) of the dgit-repos will read much more than they are
written. So that seens to emphasise the second point. I'm still not
entirely sure whether I should just use the default options to git-gc
but that's probably a good starting point.
Does that seem right ?
I have an outstanding question: do I need to lock against concurrent
updates by other programs ? That is, can I run git-gc and (say)
git-receive-pack at the same time, safely ?
Also, I still wonder if better documentation in git might help.
Thanks,
Ian.
[1] Large repos are to be expected occasionally.
--
Ian Jackson <[email protected]> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
