On 12/7/07, David Brown <git@xxxxxxxxxx> wrote: > On Fri, Dec 07, 2007 at 10:29:31PM -0500, Jon Smirl wrote: > >The kernel repo has the same problem but not nearly as bad. > > > >Starting from a default pack > > git repack -a -d -f --depth=1000 --window=1000 > >Uses 1GB of physical memory > > > >Now do the command again. > > git repack -a -d -f --depth=1000 --window=1000 > >Uses 1.3GB of physical memory > > With my repo that contains a bunch of 50MB tarfiles, I've found I must > specify --window-memory as well to keep repack from using nearly unbounded > amounts of memory. Perhaps it is the larger files found in gcc that > provokes this. > > A window size of 1000 can take a lot of memory if the objects are large. This is a partial solution to the problem. Adding window size =256M took memory consumption down from 4.8GB to 2.8GB. It took an hour to run the test. It not the complete solution since my git process is still using 2.4GB physical memory. I also still experiencing a lot of slow down in the last 10%. Does the gcc repo contain some giant objects? Why wasn't the memory freed after their chain was processed? Most of the last 10% is being done on a single CPU. There must be a chain of giant objects that is unbalancing everything. -- Jon Smirl jonsmirl@xxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
