diff options
| author | Patrick Steinhardt <psteinhardt@gitlab.com> | 2022-03-29 09:04:05 +0300 |
|---|---|---|
| committer | Patrick Steinhardt <psteinhardt@gitlab.com> | 2022-03-29 09:15:04 +0300 |
| commit | b0dd8088588a31bdd522e1f76144a0d232ffaa7c (patch) | |
| tree | 1ac8d614068b915bca580fe46049ef5acc0b8c7c | |
| parent | b2d62949e1855d4b72a39818fc09250365f230dd (diff) | |
git: Limit number of threads in git-grep(1)
Similar to git-pack-objects(1), git-grep(1) also spawns as many threads
as there are CPU cores. This has caused multiple incidents already when
there had been multiple invocations of this command in biggish repos
because we start to exhaust CPUs quite fast.
Limit the number of threads for git-grep(1) in the same way as we limit
git-pack-objects(1).
Changelog: performance
| -rw-r--r-- | internal/git/command_description.go | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/internal/git/command_description.go b/internal/git/command_description.go index 162ab30a3..d68560554 100644 --- a/internal/git/command_description.go +++ b/internal/git/command_description.go @@ -128,6 +128,12 @@ var commandDescriptions = map[string]commandDescription{ // git-grep(1) does not support disambiguating options from paths from // revisions. flags: scNoRefUpdates | scNoEndOfOptions, + opts: []GlobalOption{ + // This command by default spawns as many threads as there are CPUs. This + // easily impacts concurrently running commands by exhausting cores and + // generating excessive I/O load. + ConfigPair{Key: "grep.threads", Value: threadsConfigValue(runtime.NumCPU())}, + }, }, "hash-object": { flags: scNoRefUpdates, |