Gitlab: consumo de memoria extremadamente alto por el proceso "paquete" de ruby

9

Tengo un problema con mi instalación de Gitlab ejecutándose en un pequeño Ubuntu LTS 16.04. Tengo que señalar que no tengo mucha experiencia con Linux o Gitlab.

Mi instalación de Gitlab con algunos proyectos personales (solo 4) estaba funcionando bien, aunque empujar es extremadamente lento y a veces falla. También acceder a la interfaz web es extremadamente lento. Revisé el servidor y noté que se usaba hasta el 96% de la memoria total. El culpable parece ser un proceso conjunto.

top - 00:15:30 up 59 days, 16:17,  1 user,  load average: 0.00, 0.01, 0.09
Tasks: 160 total,   1 running, 159 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.5 us,  0.2 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 72.4/2048272  [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                           ]
KiB Swap:  0.0/0        [                                                                                                    ]

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 8760 git       20   0  648908 412768  14700 S   0.7 20.2   0:30.58 bundle
 8799 git       20   0  513748 302632  14300 S   0.0 14.8   0:20.02 bundle
 8833 git       20   0  513748 293028   4696 S   0.0 14.3   0:00.03 bundle
 8839 git       20   0  513748 292904   4572 S   0.0 14.3   0:00.02 bundle
 8836 git       20   0  513748 292840   4508 S   0.3 14.3   0:00.04 bundle
11792 mysql     20   0 1567168 158296      0 S   0.0  7.7   5:01.31 mysqld
32688 root      20   0 11.279g  99476   1164 S   0.0  4.9   1:21.06 dotnet
 8092 gitlab-+  20   0  576816  39616  39020 S   0.0  1.9   0:00.10 postgres
 8854 gitlab-+  20   0  595572  15004  10524 S   0.0  0.7   0:00.09 postgres
 8075 git       20   0  128348  14896   7680 S   0.0  0.7   0:00.07 gitlab-workhors
 8830 gitlab-+  20   0  592816  12196   9780 S   0.0  0.6   0:00.04 postgres
 9534 gitlab-+  20   0  592824  12060   9668 S   0.0  0.6   0:00.01 postgres
 8781 gitlab-+  20   0  592816  11932   9616 S   0.0  0.6   0:00.02 postgres
32684 root      20   0   61856  11420      0 S   0.0  0.6  23:35.39 supervisord
 8100 gitlab-+  20   0   37552  11112   2868 S   0.3  0.5   0:03.74 redis-server
 8094 gitlab-+  20   0  577068   7944   7324 S   0.0  0.4   0:00.01 postgres
 8087 gitlab-+  20   0   46756   7932   2900 S   0.0  0.4   0:00.01 nginx
 8095 gitlab-+  20   0  577068   7052   6444 S   0.0  0.3   0:00.06 postgres
 8088 gitlab-+  20   0   46412   6752   1992 S   0.0  0.3   0:00.10 nginx
  975 root      20   0   38236   6368   1908 S   0.0  0.3   8:47.56 systemd-journal
 8097 gitlab-+  20   0  578076   5600   4240 S   0.0  0.3   0:00.05 postgres
 8086 root      20   0   42240   5524   4696 S   0.0  0.3   0:00.00 nginx
  974 root      20   0   12204   4720     60 S   0.0  0.2   2:33.12 haveged
    1 root      20   0  185260   4308   2408 S   0.0  0.2   3:23.22 systemd
 7757 root      20   0   25224   4256   2484 S   0.0  0.2   0:00.28 bash
 9857 root      20   0   42468   3708   3076 R   0.0  0.2   0:00.09 top
 8098 gitlab-+  20   0   26956   3296   2608 S   0.0  0.2   0:00.08 postgres
 8089 gitlab-+  20   0   42424   3260   2224 S   0.0  0.2   0:00.01 nginx
 8784 git       20   0   18100   2980   2664 S   0.0  0.1   0:00.38 gitlab-unicorn-
 8096 gitlab-+  20   0  577068   2932   2332 S   0.0  0.1   0:00.03 postgres

Llegué a pstree y estos procesos de paquete parecen estar relacionados con la aplicación ruby ​​(debe ser gitlab).

systemd─┬─agetty
        ├─atd
        ├─bundle─┬─3*[bundle───{ruby-timer-thr}]
        │        └─{ruby-timer-thr}
...

¿Alguien ha tenido experiencias similares o una idea de lo que podría causar esto?

linux ruby gitlab ubuntu-16.04 mode777
fuente

Respuestas:

3

GitLab CE quiere usar al menos 4 GB de RAM. Entonces, si tiene 2 GB de RAM, GitLab intenta agregar otros 2 GB de memoria mediante SWAP, lo que da como resultado 2 GB de memoria de intercambio. Esto hace que GitLab sea muy lento, incluso si eres el único usuario.

La solución: su máquina debe tener al menos 4 GB de RAM o más. No pierdas tu tiempo ajustando el archivo de configuración de GitLab, solo asegúrate de tener 4 GB de RAM.

Lea la sección 'Memoria' de este documento de GitLab: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/requirements.md

¡Buena suerte!

Andaluz
fuente
2

Esos serán los trabajadores unicornio y sidekiq. Parecen estar usando la cantidad correcta de memoria. 2 GB es aproximadamente el mínimo de RAM para ejecutar gitlab; Si su sistema tiene mucha actividad, querrá 4 GB o más.

También tengo una instancia personal de gitlab en 2GB de RAM, y muestra un uso similar:

top - 23:30:42 up 5 days,  7:53,  1 user,  load average: 0.04, 0.03, 0.05
Tasks: 172 total,   2 running, 170 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.2 us,  0.2 sy,  0.0 ni, 98.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  2048816 total,    72636 free,  1762504 used,   213676 buff/cache
KiB Swap:  1048572 total,   801180 free,   247392 used.    73972 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
  664 git       20   0  715620 458296   2964 S   3.0 22.4 139:48.55 bundle      
 1623 git       20   0  543608 327472   3044 S   0.0 16.0   3:46.02 bundle      
 1626 git       20   0  543608 324384   3224 S   0.0 15.8   3:51.97 bundle      
 1620 git       20   0  543608 324244   3088 S   0.0 15.8   3:51.68 bundle      
 1556 git       20   0  510840 149736   2616 S   0.0  7.3   0:18.45 bundle

Tenga en cuenta que topno le muestra lo que realmente están haciendo los procesos, pero puede averiguarlo fácilmente ps. Por ejemplo:

# ps 664
  PID TTY      STAT   TIME COMMAND
  664 ?        Ssl  139:49 sidekiq 4.2.1 gitlab-rails [0 of 25 busy]
# ps 1556
  PID TTY      STAT   TIME COMMAND
 1556 ?        Sl     0:18 unicorn master -D -E production -c /var/opt/gitlab/gitlab-rails/etc/unicorn.rb /opt/gitlab/embedded/service/gitlab-rails/config.ru
Michael Hampton
fuente
1
Gracias por su respuesta. Creo que tendré que buscar una solución más ligera. Gogs parece prometedor
mode777
También tengo 2 gb de RAM y gitlab funciona bien al principio. Parece que hay una pérdida de memoria en el compinche ( gitlab.com/gitlab-org/gitlab-ce/issues/30564 ). Hay algunas cosas que puede hacer como: docs.gitlab.com/ce/administration/operations/… (pero no lo he hecho yo mismo) o reiniciar ese proceso de compinche de vez en cuando (¿tal vez un cron?).
Josejulio
Unicorn Killer
Josejulio
Estoy evaluando gitlab para un proyecto y he encontrado un problema similar aquí en marzo de 2018. Una nueva instalación brillante de Debian en un nodo de 2 gb, Gitlab funciona bien, pero durante unos días los bundleprocesos consumen memoria y causan un intercambio excesivo. Esto se solucionó, al menos temporalmente, con gitlab-ctl restart. "Gitlab tiene pérdidas de memoria", dice la documentación. Sí, tiene fugas desde el momento en que lo instala, cuando está inactivo.
Roger Halliburton
Puede presionar cen la parte superior para mostrar las líneas de comando reales.
Thomas
1

Sé que este hilo es un poco rancio, pero ¿alguien más todavía se encuentra con esto? Estoy en una caja física con 24 GB y 12 núcleos / 24 hilos y veo un paquete bifurcado como loco hasta que se agota toda la memoria. Miré en la configuración de gitlab y encontré que la concurrencia de sidekiq está configurada en 25 de forma predeterminada, ¿aparentemente eso significa que se ejecutan hasta 25 copias del paquete? Crea tantos como puede antes de memoria. Loco.

BoeroBoy
fuente
Actualización Encontré este hilo que ayuda: stackoverflow.com/questions/36122421/…
BoeroBoy
0

¿Has intentado apagarlo y volver a encenderlo?

gitlab-ctl restart

Pase lo que pase bundle, parece bastante claro que las herramientas * -killer no están captando estos problemas. Parece que estos procesos se inician desde sidekiq.

Roger Halliburton
fuente