Re: Git import of cvs2git dumpfile

Fabian Schäfer <[email protected]> Mon, 12 Aug 2013 15:28:15 +0200
Newsgroups gmane.comp.version-control.subversion.cvs2svn.user
Message-ID <CAGrb+mQSM9VryOize+_ieM0Ej4ss=EAQaqgQoqHy-XGTXaLnSQ@mail.gmail.com>
>What command did you use to load the files?  Did it crash when loading
>the blob file or the dump file or did you load them both at the same
>time?  If you were loading them at the same time, you might try loading
>them separately:
>
>    git fast-import --export-marks=FILENAME <git-blob.dat
>    git fast-import --import-marks=FILENAME <git-dump.dat
>
>and see which of the processes dies.

I tried both. And the blob-file import does work very well. It interrupts
when I try to import the dump file.



>Did you monitor the size of the "git fast-import" process before it
>died?  Was it slowly eating up the available 72 Gb?

Yes, I have monitored the consumption. the process uses less than 10% of
memory. So a swapfile is never used.

Best Regards,
Fabian


2013/8/11 Michael Haggerty <[email protected]>

> On 08/11/2013 05:01 PM, Fabian Schäfer wrote:
> > I have successfully migrated my 13GB cvs repository with cvs2git. But
> > now I get an out-of-memory error by using the git fast-import:
> >
> > |fatal: Out of memory, malloc failed (tried to allocate **6196691
> bytes**)
> > fast-import: dumping crash report to fast_import_crash_13097
> > error: git-fast-import died of signal 11
>
> "git fast-import" is separate from cvs2git, so if it is failing then you
> might have better luck asking on the Git mailing list.  But...
>
> What did the crash report say?
>
> > |I have already tried to unlimit stacksize and file descriptors.
> > Also I have searched for the biggest file in the repository: 130MB.
> > |
> >
> > |My System has 32 GB RAM and 40GB Swap, the dump file is 72GB and the
> > blob file 10GB big. I am running the import on a RHEL5.3 with
> > Git 1.8.3.4, Python 2.6.8, GCC44.
>
> What command did you use to load the files?  Did it crash when loading
> the blob file or the dump file or did you load them both at the same
> time?  If you were loading them at the same time, you might try loading
> them separately:
>
>     git fast-import --export-marks=FILENAME <git-blob.dat
>     git fast-import --import-marks=FILENAME <git-dump.dat
>
> and see which of the processes dies.
>
> The Python version is irrelevant, since it is "git fast-import" that is
> failing.
>
> It is funny that RAM + Swap = 72 GB = size of dump file, but I suppose
> it is just a coincidence.
>
> Did you monitor the size of the "git fast-import" process before it
> died?  Was it slowly eating up the available 72 Gb?
>
> > |I have read in an older post that it is maybe possible
> > to split the dump file into smaller pieces. How is this possible?
> > |Can someone please give me an hint?
>
> Hmmm, I suppose it would be possible if you break it at allowed
> boundaries and do the --export-marks/--input-marks thing between runs.
> See the git-fast-import(1) man page for details about the format.
>
> But if it is the marks table that is filling up your memory, then
> splitting up the input files might not help.
>
> Michael
>
> --
> Michael Haggerty
> [email protected]
> http://softwareswirl.blogspot.com/
>

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=3062470

To unsubscribe from this discussion, e-mail: [[email protected]].