¿Hay alguna forma de limitar la cantidad de memoria que usa "git gc"?

memory dreamhost

Question

Estoy organizando un git repo en un host compartido. Mi informe necesariamente tiene un par de archivos muy grandes, y cada vez que trato de ejecutar "git gc" en el repositorio ahora, el proveedor de alojamiento compartido mata mi proceso por usar demasiada memoria. ¿Hay alguna manera de limitar la cantidad de memoria que git gc puede consumir? Mi esperanza es que pueda cambiar el uso de la memoria por velocidad y solo demore un poco más en hacer su trabajo.

Answer 1

El uso de memoria de Git repack es: (pack.deltaCacheSize + pack.windowMemory) × pack.threads . Los valores predeterminados respectivos son 256Mib, ilimitados, nproc.

La memoria caché delta no es útil: la mayor parte del tiempo se utiliza para calcular deltas en una ventana deslizante, la mayoría de las cuales se descartan; el almacenamiento en caché de los supervivientes para que puedan volver a utilizarse una vez (al escribir) no mejorará el tiempo de ejecución. Ese caché tampoco se comparte entre subprocesos.

Por defecto, la memoria de la ventana está limitada a través de pack.window ( gc.aggressiveWindow ). Limitar el empaque de esa manera es una mala idea, porque el tamaño y la eficiencia del conjunto de trabajo variarán ampliamente. Lo mejor es elevar ambos a valores mucho más altos y confiar en pack.windowMemory para limitar el tamaño de la ventana.

Finalmente, el enhebrado tiene la desventaja de dividir el conjunto de trabajo. Bajar los pack.threads y aumentar pack.windowMemory para que el total permanezca igual debería mejorar el tiempo de ejecución.

reempaquetar tiene otros parámetros optimizables útiles ( pack.depth , pack.compression , las opciones de mapa de bits), pero no afectan el uso de la memoria.

Answer 2

Git 2.18 (Q2 2018) mejorará el consumo de memoria de gc.
Antes de 2.18, " git pack-objects " necesita asignar toneladas de " struct object_entry " mientras hace su trabajo: reducir su tamaño ayuda bastante al rendimiento .
Esto influye en git gc .

Ver commit f6a5576 , commit 3b13a5f , commit 0aca34e , commit ac77d0c , commit 27a7d06 , commit 660b373 , commit 0cb3c14 , commit 898eba5 , commit 43fa44f , commit 06af3bb , commit b5c0cbd , commit 0c6804a , commit fd9b1ba , commit 8d6ccce , commit 4c2db93 (14 abr 2018) por Nguyễn Thái Ngọc Duy ( pclouds ) .
^{(Fusionado por Junio ​​C Hamano - gitster - en commit ad635e8 , 23 de mayo de 2018)}

pack-objects : reordenar miembros para reducir la struct object_entry

Los parches anteriores dejan muchos agujeros y relleno en esta estructura.
Este parche reordena los miembros y reduce la estructura a 80 bytes (desde 136 bytes en sistemas de 64 bits, antes de que se reduzca el campo) con 16 bits de repuesto (y un par más en in_pack_header_size cuando realmente nos quedemos sin bits) .

Este es el último de una serie de parches de reducción de memoria (ver " pack-objects: un poco de documento sobre struct object_entry " para el primero).

En general, redujeron el tamaño de la memoria de reempaquetado en linux-2.6.git de 3.747G a 3.424G, o alrededor de 320M, una disminución de 8.5%.
El tiempo de ejecución de reembalaje se ha mantenido igual a lo largo de esta serie.
Las pruebas de Ævar en un monorepo grande al que tiene acceso (más grande que linux-2.6.git ) han mostrado una reducción del 7.9%, por lo que la mejora general esperada debería rondar el 8%.

Answer 3

Puede usar desactivar el atributo delta para deshabilitar la compresión delta para solo los blobs de esos nombres de ruta:

En foo/.git/info/attributes (o foo.git/info/attributes si es un repositorio vacío) (ver la entrada delta en gitattributes y ver gitignore para la sintaxis del patrón):

/large_file_dir/* -delta
*.psd -delta
/data/*.iso -delta
/some/big/file -delta
another/file/that/is/large -delta

Esto no afectará a los clones del repositorio. Para afectar a otros repositorios (es decir, clones), coloque los atributos en un archivo .gitattributes lugar de (o además de) el archivo de info/attributes .

Answer 4

Sí, eche un vistazo a la página de ayuda de git config y mire las opciones del pack.* , Específicamente pack.depth , pack.window , pack.windowMemory y pack.deltaCacheSize .

No es un tamaño totalmente exacto ya que git necesita asignar cada objeto a la memoria para que un objeto muy grande pueda causar una gran cantidad de uso de la memoria, independientemente de la ventana y la configuración de la memoria caché delta.

Puede tener mejor suerte empacando localmente y transfiriendo los archivos del paquete al lado remoto "manualmente", agregando archivos .keep para que el git remoto nunca intente volver a empaquetar todo.

Answer 5

Utilicé instrucciones de este link . La misma idea que Charles Baileys sugirió.

Una copia de los comandos está aquí:

git config --global pack.windowMemory "100m"
git config --global pack.packSizeLimit "100m"
git config --global pack.threads "1"

Esto funcionó para mí en hostgator con una cuenta de hosting compartido.