On Mon, 6 Apr 2009, Nguyen Thai Ngoc Duy wrote: > On Mon, Apr 6, 2009 at 9:38 AM, Robin H. Johnson <robbat2@xxxxxxxxxx> wrote: > > Looking at the source, I agree that it should be buffering, however top and ps > > seem to disagree. 3GiB VSZ and 2.5GiB RSS here now. > > > > %CPU %MEM VSZ RSS STAT START TIME COMMAND > > 0.0 0.0 140932 1040 Ss 16:09 0:00 \_ git-upload-pack /code/gentoo/gentoo-git/gentoo-x86.git > > 32.2 0.0 0 0 Z 16:09 1:50 \_ [git-upload-pack] <defunct> > > 80.8 44.2 3018484 2545700 Sl 16:09 4:36 \_ git pack-objects --stdout --progress --delta-base-offset > > > > Also, I did another trace, using some other hardware, in a LAN setting, and > > noticed that git-upload-pack/pack-objects only seems to start output to the > > network after it reaches 100% in 'remote: Compressing objects:'. > > > > Relatedly, throwing more RAM (6GiB total, vs. the previous 2GiB) at the server > > in this case cut the 200 wallclock minutes before any sending too place down to > > 5 minutes. > > Searching back the archive, there was memory fragmentation issue with > gcc repo. I wonder if it happens again. Maybe you should try Google > allocator. BTW, did you try to turn off THREADED_DELTA_SEARCH? That was for a _full_ repack, i.e. 'git repack -a -f'. This is never the case on a fetch/clone, like in this case, unless you have all your objects in loose form. Nicolas