git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Strategy to deal with slow cloners

From
Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date
Apr 19, 2021, 12:46 UTC
Message-ID
<20210419124623.wwps2s35x2mrrhi6@nitro.local>
Hello:

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?

-K
Next: Eric Wong
Message 1 of 6 in “Strategy to deal with slow cloners”
  1. Konstantin RyabitsevApr 19, 2021
  2. Eric WongApr 19, 2021
  3. Eric WongApr 21, 2021
  4. Thomas BraunApr 20, 2021
  5. Ævar Arnfjörð BjarmasonApr 22, 2021
  6. Jeff KingApr 23, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.