All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Pierre Bruno <pierrebruno@hotmail.ch>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Windows: ~1 GB RAM per git process, many concurrent (2.56.0.windows.1)
Date: Fri, 2 Oct 2026 19:28:45 +0000	[thread overview]
Message-ID: <asAF7D_XefgKtgf6@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <BL0PR05MB5603A8CE8FD78127FB810BE2D8892@BL0PR05MB5603.namprd05.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

On 2026-10-02 at 11:04:00, Pierre Bruno wrote:
> Hi,
> 
> On Windows, git status-type commands use about 1 GB of RAM per
> process, and dozens run at once when I use coding agents (OpenCode and
> Oh My Pi) in a repository. CPU is near 0%, disk I/O is steady, and the
> total is several GB. Since two unrelated tools cause it, I suspect git
> or my repo.
> 
> Expected: a few short-lived git processes with far less memory.
> 
> git version 2.56.0.windows.1 (commit 49d759b698127791a5f3f2759c69b983846711dd,
> fsmonitor--daemon enabled), Windows <version>
> Repo: <N files / GB>, <N> untracked files
> Manual 'git status' with no other tool running: <fast/slow, memory>
> Stable 2.55.0: <same/different>
> Command line seen in Task Manager: <paste>
> 
> Is ~1 GB per process expected here, and is there a recommended config to
> reduce it? Full 'git bugreport' attached.

I think you omitted the attachment, but in any event, I would say that
this is not normally expected for `git status`.  We'd really need to
know what the command line of those processes is for us to know what
they're for; for instance, you may be triggering maintenance on the
repository, in which case packing a large repository could legitimately
use that much memory.  Similarly, if you're using a file system monitor
process, that could consume a large amount of memory in a large
repository.

I don't personally use Windows, so I'm afraid I can't tell you how to
get that information there.  Once you have it, though, it should be
clearer if that's a reasonable amount of memory to be using given the
size of your repository.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

  reply	other threads:[~2026-10-02 19:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-02 11:04 Windows: ~1 GB RAM per git process, many concurrent (2.56.0.windows.1) Pierre Bruno
2026-10-02 19:28 ` brian m. carlson [this message]
2026-10-02 22:19 ` Jeff King

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=asAF7D_XefgKtgf6@fruit.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=pierrebruno@hotmail.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.