tag - Alto uso de memoria para Gitlab CE

qué tipos de etiquetas existen en git

Question

Mira esta imagen que muestra el consumo de memoria de gitlab ce.

Realmente no necesito a todos esos trabajadores, sidekiq o unicornio o todos esos demonios. Esto está en IDLE. Quiero decir, instalé esto para administrar 1 proyecto, con como 4 personas, no necesito todos esos demonios. ¿Hay alguna manera de reducir esto?

Answer 1

2 Opciones que encontré navegando el gitlab.rb

1. sidekiq[''concurrency''] = 1 #25 is the default
2. unicorn[''worker_processes''] = 1 #2 is the default

Y esto que necesita ser comprendido de acuerdo a su advertencia:

## Only change these settings if you understand well what they mean
## see https://about.gitlab.com/2015/06/05/how-gitlab-uses-unicorn-and-  unicorn-worker-killer/
## and https://github.com/kzk/unicorn-worker-killer
# unicorn[''worker_memory_limit_min''] = "300*(1024**2)"
# unicorn[''worker_memory_limit_max''] = "350*(1024**2)"

Esto es después de modificaciones de configuración.

Todavía es demasiado en mi opinión.

Answer 2

Dado que GitLab 9.0, prometheus está habilitado de forma predeterminada, me di cuenta de que en mi caso utilizaba mucha memoria de más de 1.5GB, esto se puede deshabilitar con prometheus_monitoring[''enable''] = false

Answer 3

Desde su imagen, parece que Sidekiq y todos sus trabajadores están usando una suma total de 257 mb de memoria, lo que es normal. Recuerde que todos los trabajadores de Sidekiq usan el mismo conjunto de memoria, por lo que están usando un total de 257 mb, no 257 mb cada uno. Como ha visto en su propia respuesta, reducir el número de trabajadores de Sidekiq no reducirá drásticamente el uso de la memoria, sino que hará que los trabajos en segundo plano tomen más tiempo porque tienen que esperar para que esté disponible un proceso Sidekiq. Dejaría este valor en el valor predeterminado, pero si realmente quiere disminuirlo, entonces no lo haría por debajo de 4, ya que tiene 4 núcleos.

Los procesos Unicornio también comparten un grupo de memoria, pero cada trabajador tiene 1 grupo que se comparte entre sus 2 procesos. En su imagen original, parece que tiene 5 trabajadores, lo que se recomienda para un sistema de 4 núcleos, y cada uno utiliza aproximadamente ~ 250 m de memoria. No debería notar ninguna diferencia de rendimiento si reduce el número de trabajadores a 3.

Además, es posible que desee leer este documento sobre cómo configurar Unicorn. Definitivamente no desea que el número de trabajadores sea menor que 2 porque causa problemas al editar archivos desde la interfaz de usuario de GitLab, como se explica aquí , y también desactiva la clonación a través de HTTPS según esta cita del documento que vinculé:

Con un trabajador Unicorn, solo el acceso git sobre ssh funcionará porque el acceso git sobre HTTP requiere dos trabajadores en ejecución (un trabajador para recibir la solicitud del usuario y un trabajador para la verificación de autorización).

Finalmente, las versiones recientes de GitLab parecen asignar más memoria al caché de la base de datos postgresql. Recomiendo configurar esta propiedad postgresql[''shared_buffers''] en /etc/gitlab/gitlab.rb para que sea 1/4 de su RAM libre total. Vea la respuesta de René Link a continuación para obtener más información al respecto.

Answer 4

También tuve problemas con el alto consumo de memoria de gitlab. Así que me encontré con la herramienta linux htop .

En mi caso, descubrí que el servicio postgresl usaba la mayor parte de la memoria.

Con el servicio postgres corriendo se utilizaron 14.5G de 16G.

Detuve un servicio de gitlab tras otro y descubrí que cuando detenía postgres se liberaba una gran cantidad de memoria.

Puedes probarlo

gitlab-ctl stop postgresql

y volver a empezar el servicio con

gitlab-ctl start postgresql

Finalmente encontré la siguiente configuración en /etc/gitlab/gitlab.rb

##! **recommend value is 1/4 of total RAM, up to 14GB.**
# postgresql[''shared_buffers''] = "256MB"

Acabo de establecer los búferes compartidos en 256 MB eliminando el comentario # , porque 256 MB son suficientes para mí.

postgresql[''shared_buffers''] = "256MB"

y ejecutado gitlab-ctl reconfigure . gitlab-ctl reinicia los servicios afectados y el consumo de memoria ahora es muy moderado.

Esperemos que eso ayude a alguien más.

Answer 5

Ya he arreglado este caso.
¡El que más memoria utiliza es el unicornio!
La versión de mi gitlab fue "GitLab Community Edition 10.6.3".
Y fue instalado en mi servidor, es CPU, INTEL Core i5 8400 para seis núcleos.
Entonces gitlab asigna 7 progresos para unicornio, cada progreso ocupó 6% mem.

Método:
vim /var/opt/gitlab/gitlab-rails/etc/unicorn.rb
Cómo editar el unicornio.rb
Editar y guardar cambios. Y ejecuta "gitlab-ctl restart unicorn"
El htop detrás de unicorn.rb cambia.