Re: git pack-objects run amok

[Jim Meyering <jim at meyering dot net>]

Frank Ch. Eigler wrote:
>> The load average on gcc.gnu.org was in the 300-400 range for a while
>> tonight.  The culprit was apparently due to a lot of these [...]
>> git pack-objects --revs --thin --stdout --delta-base-offset [...]
>
> I added some /etc/xinetd.d/git-daemon constraints in an attempt to
> preclude a reoccurrance, kind of like the anon-cvs limits.

Hi Frank,

You can reduce the effect of the requests that provoked that by
running "git gc" on repositories for which "git count-objects"
reports more than a few megabytes.  That is something I do every
month or two on all of the git repositories at savannah.gnu.org.

For example, I see that glibc has 34MB (of 135MB) worth of not-packed objects:

  $ git count-objects
  2483 objects, 34872 kilobytes

After your "git gc" run, that will be 0.
This makes an especially big difference when the repository
is stored on spinning rust: far fewer seeks.  Of course, with
SSDs the seek effect is negligible, but the smaller footprint
helps even there.

Sometimes it's good to run the much more time/resource-consuming repack
operation, too:

I use this bash function:

git-repo-compress()
{
  local d=$1
  du -sh "$d"; start=$(date); /usr/bin/time \
    git --git-dir="$d" repack -afd --window=250 --depth=250
  echo started $start; date; du -sh "$d"
}

To give you an idea, on my local glibc clone, "git gc" reduced
"du -sh .git" from 134M to 92M.  Just to see, I ran the above
git-repo-compress and it shaved off only 3MB resulting in 89MB,
so the git-repo-compress run is not worth it, considering the cost.