Re: Strategy to deal with slow cloners

From: Thomas Braun <thomas.braun@virtuell-zuhause.de>
Date: Apr 20, 2021, 14:52 UTC
Message-ID: <f3b406a7-90cd-89c1-c532-d9a7c0f71599@virtuell-zuhause.de>
In-Reply-To: <20210419124623.wwps2s35x2mrrhi6@nitro.local>

On 19.04.2021 14:46, Konstantin Ryabitsev wrote:

Show 10 quoted lines

> I try to keep repositories routinely repacked and optimized for clones, in
> hopes that most operations needing lots of objects would be sending packs
> straight from disk. However, every now and again a client from a slow
> connection requests a large clone and then takes half a day downloading it,
> resulting in gigabytes of RAM being occupied by a temporary pack.
> 
> Are there any strategies to reduce RAM usage in such cases, other than
> vm.swappiness (which I'm not sure would work, since it's not a sleeping
> process)? Is there a way to write large temporary packs somewhere to disk
> before sendfile'ing them?

There is the packfile-uris feature which allows protocol v2 servers to advertise static packfiles via http/https. But clients must explicitly enable it via fetch.uriprotocols. So this does only work for newish clients which explicitly ask for it. See Documentation/technical/packfile-uri.txt.

From my limited understanding one clone/fetch the server can only send one packfile at most.

What is the advertised git clone command on the website? Maybe something like git clone --depth=$num would help reduce the load? Usually not everyone needs the whole history.