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? -- Duy -- 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