git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ian Kumlien <pomac@vapor.com>
To: git@vger.kernel.org
Cc: pclouds@gmail.com
Subject: Re: [FYI] very large text files and their problems.
Date: Wed, 22 Feb 2012 19:39:40 +0100	[thread overview]
Message-ID: <1329935980.23912.5.camel@pi> (raw)

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

Seems like i ruined my dovecot config in a recent upgrade - which also
affected my mail... =/

Anyway, it's all fixed now.

from: Nguyen Thai Ngoc Duy <pclouds () gmail ! com>
> On Wed, Feb 22, 2012 at 10:49 PM, Ian Kumlien <pomac@vapor.com> wrote:
> > Hi,
> >
> > We just saw a interesting issue, git compressed a ~3.4 gb project to
> ~57 mb.
> 
> How big are those files? How many of them? How often do they change?

This is the initial check in, one of the files is a 3.3 gb text file.

> > But when we tried to clone it on a big machine we got:
> >
> > fatal: Out of memory, malloc failed (tried to allocate
> > 18446744072724798634 bytes)
> >
> > This is already fixed in the 1.7.10 mainline - but it also seems
> like
> 
> Does 1.7.9 have this problem?

I've tested with 1.7.9.1, haven't downgraded to test with 1.7.9...

> > git needs to have atleast the same ammount of memory as the largest
> > file free... Couldn't this be worked around?
> >
> > On a (32 bit) machine with 4GB memory - results in:
> > fatal: Out of memory, malloc failed (tried to allocate 3310214313
> bytes)
> >
> > (and i see how this could be a problem, but couldn't it be
> mitigated? or
> > is it bydesign and intended behaviour?)
> 
> I think that it's delta resolving that hogs all your memory. If your
> files are smaller than 512M, try lower core.bigFileThreshold. The
> topic jc/split-blob, which stores a big file are several smaller
> pieces, might solve your problem. Unfortunately the topic is not
> complete yet.

the problem here is that there is one file that is exactly: 3310214313
bytes, so it should all be one "blob".

split-blob would be really interesting for several reasons though =)

> -- 
> Duy
> --
-- 
Ian Kumlien  -- http://demius.net || http://pomac.netswarm.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

             reply	other threads:[~2012-02-22 18:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-22 18:39 Ian Kumlien [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-02-22 15:49 [FYI] very large text files and their problems Ian Kumlien
2012-02-22 16:18 ` Nguyen Thai Ngoc Duy
2012-02-24 10:11   ` Ian Kumlien
2012-02-24 11:14     ` Nguyen Thai Ngoc Duy
2012-02-24 12:55       ` Ian Kumlien

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=1329935980.23912.5.camel@pi \
    --to=pomac@vapor.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).