From: Thomas <th.acker66@arcor.de>
To: git@vger.kernel.org
Subject: Re: Large repo and pack.packsizelimit
Date: Wed, 9 May 2012 11:46:13 +0000 (UTC) [thread overview]
Message-ID: <loom.20120509T131228-943@post.gmane.org> (raw)
In-Reply-To: CACsJy8BhSn+PB5tXME-w_cq4DVd2BULNRNLV-vk1_6yWKy+fNg@mail.gmail.com
Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
>
> On Wed, May 9, 2012 at 4:36 PM, Thomas <th.acker66 <at> arcor.de> wrote:
> > To be exact I did the clone locally on the same machine and so the clone
itself
> > worked
> > but I got the OOM during the first fetch. I "fixed" this by setting
> > transfer.unpacklimit=100000
> > which caused only loose objects to be transfered.
> > So in this case I think the OOM was on the remote side. But there is another
OOM
> > if I try to repack locally.
> > It seems to me that neither pack-objects nor index-pack respekt
> > pack.packsizelimit and always
> > try to pack all objects to be transferred resp. all local loose objects in
one
> > pack.
> > I could live wth the transfer.unpacklimit=100000 but the local OOM stops me
from
> > using the cloned repo.
>
> I have some patches to make index-pack work better with large blobs
> but they're not ready yet. I think pack-objects works fine with large
> blobs as long as they are all in packs. Are there any loose objects on
> the source repo?
>
> It's strange that you chose "256mb" as the upper limit for small
> objects in your first mail. Do you have a lot of >=10mb files? By
> default, files smaller than 512mb will be put in memory for delta. A
> lot of big (but smaller than 512mb) files can quickly consume all
> memory. If it's the case, maybe you can lower core.bigFileThreshold
>
> Also maybe try remove the 1.2GB file from the source repo and see if
> it works better. That could give us some hints where the problem is.
I am using core.bigFileThreshold=256MB already; so the large file/s should not
be the problem (most of the files in the repo are "standard" source code files;
I tried even smaller numbers for bigFileThreshold and packsizelimit but with no
success).
As long as I worked with the original repo which was updated regularily all
worked well as soon as pack.packsizelimit was set to 1024MB (even with the 1.2GB
file). Repack seems not to increase a pack further as soon as packsizelimit is
exceeded (so my packs are all slightly larger than 1024MB) BUT it also seems to
try to put everything in one pack regardless of packsizelimit in the following
cases:
(1) all objects to be transferred to another repo
(2) all loose objects when starting a local repack
Case (1) can be fixed by transfer.unpacklimit but there is no fix for (2).
---
Thomas
next prev parent reply other threads:[~2012-05-09 11:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-03 11:57 Large repo and pack.packsizelimit th.acker66
2012-05-08 20:31 ` Jeff King
2012-05-08 21:13 ` Nicolas Pitre
2012-05-08 21:20 ` Jeff King
2012-05-08 21:52 ` Nicolas Pitre
2012-05-09 9:36 ` Thomas
2012-05-09 10:50 ` Nguyen Thai Ngoc Duy
2012-05-09 11:46 ` Thomas [this message]
2012-05-09 17:30 ` Junio C Hamano
2012-05-10 11:42 ` Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20120509T131228-943@post.gmane.org \
--to=th.acker66@arcor.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.