Thread (51 messages) flat view 51 messages, 14 authors, 2016-06-15

Re: pack operation is thrashing my server

From: Nicolas Pitre <hidden>
Date: 2016-06-15 22:45:09

Possibly related (same subject, not in this thread)

On Mon, 11 Aug 2008, Ken Pratt wrote:
quoted
As a quick workaround you could try it with a 32bit git executable?
(assuming you have a distribution with proper multilib support)
In this case, I do have control over the server (running Arch Linux,
which should do 32-bit multilib just fine), but for my workflow I
cannot assume that the server will have 32-bit git support.

I will use the previously mentioned solution of doing the packing
elsewhere for now as a band-aid, with hopes that this will get fixed
sometime soon.
I'm afraid no fix is "possible" since you said:
Largest object is ~150MB, and there are a couple 5-10MB objects as 
well.
If you have only 256 MB of RAM, I'm afraid the machine dives into swap 
the moment it attempts to process that single 150-MB object during 
repacking.  Objects are always allocated entirely, including the 
deflated and inflated copy at some point.  Making git handle partial 
objects in memory would add complexity all over the map so I don't think 
it'll ever be implemented nor be desirable.

If you do repack once with 'git repack -a -f -d' on a bigger machine 
then 256 MB of RAM might be fine for serving clone and fetch requests 
though.


Nicolas
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help