public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Rob Browning <rlb@defaultvalue•org>
To: git@vger•kernel.org
Subject: cat-file --batch-command info performance problem
Date: Tue, 05 Aug 2025 16:21:36 -0500	[thread overview]
Message-ID: <871ppp1n33.fsf@trouble.defaultvalue.org> (raw)


While doing some testing before a bup release, I ran in to a performance
problem that I've narrowed down to git (2.47.2) cat-file --batch-command
(currently, bup often relies on git cat-file).

I can reproduce the problem with a ~125GB (~3M object) repository on
an external SSD and a system with 16GB RAM via "git --batch-command <
fetch-oids" where fetch-oids contains 8k "info HASH" commands.

That process runs at 32 hashes/sec (overall average), with a cold
cache (echo 3 > /proc/sys/vm/drop_caches), and does not improve over
repeated runs.  While that's running, every time I check, git's
reading about 300-400+ MB/s.

That didn't seem right, so I wrote a test command that produces the same
information via direct index access and packfile reads/seeks. With a
cold cache, that runs at 1.5k hashes/sec (even from python), and on the
second or third run, 9 hashes/seck.  Interestingly, if I run cat-file
after the test command has warmed up the cache, cat-file then reaches
53k hashes/sec.

My current guess is that cat-file's approach (all mmap?) is causing
some kind of kernel derived read amplification that's vastly
increasing the working set.

This is easily repeatable here, so I'd be happy to help test if that's
desirable, and perhaps even to pursue it if I can, and if it seems like
something that could/should be addressed in git.

If not, that's also helpful to know, and then we'll just handle the
lookups ourselves.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

             reply	other threads:[~2025-08-05 21:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-05 21:21 Rob Browning [this message]
2025-08-05 22:10 ` cat-file --batch-command info performance problem Rob Browning

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871ppp1n33.fsf@trouble.defaultvalue.org \
    --to=rlb@defaultvalue$(echo .)org \
    --cc=git@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox