Nuestros desarrolladores estrellas agotaron sus reservas de café, buscando día y noche por la respuesta, hasta que Ezequiel encontró la contestación en GitLab y hoy la compartimos aquí.
Solución:
También tuve problemas con el alto consumo de memoria de gitlab. Así que ejecuté la herramienta de Linux htop.
En mi caso descubrí que el servicio postgresl usaba la mayor parte de la memoria.
Con servicio postgres ejecutándose Se utilizaron 14.5G de 16G
Detuve un servicio de gitlab tras otro y descubrí que cuando dejar de postgres se liberó mucha memoria.
Puedes probarlo
gitlab-ctl stop postgresql
y comenzar el servicio de nuevo con
gitlab-ctl start postgresql
Finalmente me encontré con 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 configurar 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.
Según su imagen, parece que Sidekiq y todos sus trabajadores están utilizando una suma total de 257 MB de memoria, lo cual es normal. Recuerde que todos los trabajadores de Sidekiq usan el mismo grupo de memoria, por lo que usan 257 mb en total, no 257 mb cada uno. Como ha visto en su propia respuesta, disminuir la cantidad de trabajadores de Sidekiq no disminuirá drásticamente el uso de la memoria, pero hará que los trabajos en segundo plano tomen más tiempo porque tienen que esperar hasta que esté disponible un proceso de Sidekiq. Dejaría este valor en el valor predeterminado, pero si realmente desea disminuirlo, no lo disminuiría por debajo de 4 ya que tiene 4 núcleos.
Los procesos Unicorn también comparten un grupo de memoria, pero cada trabajador tiene un 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 usa aproximadamente ~ 250 MB de memoria. No debería notar ninguna diferencia de rendimiento si reduce la cantidad de trabajadores a 3.
Además, es posible que desee leer este documento sobre cómo configurar Unicorn. Definitivamente no desea que la cantidad de trabajadores sea inferior a 2 porque causa problemas al editar archivos desde la interfaz de usuario de GitLab, como se explica aquí, y también deshabilita la clonación a través de HTTPS de acuerdo con esta cita del documento que vinculé:
Con un trabajador de Unicorn, solo funcionará el acceso git sobre ssh 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. Recomendaría configurar esta propiedad postgresql['shared_buffers'] en /etc/gitlab/gitlab.rb ser 1/4 de su RAM libre total. Consulte la respuesta de René Link a continuación para obtener más información al respecto.
Desde GitLab 9.0, Prometheus está habilitado de forma predeterminada, lo que noté que usaba mucha memoria de más de 1.5 GB en mi caso, esto se puede deshabilitar con prometheus_monitoring['enable'] = false
valoraciones y comentarios
Recuerda que te concedemos comentar tu experiencia si descubriste tu contrariedad en el momento cabal.