2016-03-21 10 views
17

Guardare questa immagine che mostra il consumo di memoria gitlab ce. gitlab ce memory consumptionUtilizzo memoria elevata per Gitlab CE

Non ho davvero bisogno di tutti quei lavoratori, sidekiq o unicorno o tutti quei demoni. Questo è su IDLE. Voglio dire, l'ho installato per gestire 1 progetto, con come 4 persone, non ho bisogno di tutti quei daemon. C'è un modo per ridurre questo?

+4

Per quanto io sto lottando con l'utilizzo della memoria Gitlab troppo, Non penso che questa domanda appartenga a StackOverflow. ServerFault forse? –

+3

Ho lo stesso problema, il monitoraggio di Gitlab mostra fondamentalmente 2.3 GB in modalità idle. – javydreamercsw

risposta

10

Dalla tua immagine sembra che Sidekiq e tutti i suoi dipendenti stiano utilizzando una somma totale di 257 MB di memoria, il che è normale. Ricorda che tutti i lavoratori Sidekiq utilizzano lo stesso pool di memoria, quindi utilizzano 257 MB totali, non 257 MB ciascuno. Come hai visto dalla tua risposta, la riduzione del numero di lavoratori Sidekiq non ridurrà drasticamente l'utilizzo della memoria, ma farà sì che i lavori in background richiedano più tempo perché devono aspettare che sia disponibile un processo Sidekiq. Lascerei questo valore al valore predefinito, ma se vuoi davvero ridurlo, non lo diminuirei sotto 4 dato che hai 4 core.

I processi Unicorn condividono anche un pool di memoria, ma ogni worker ha un pool condiviso tra i suoi 2 processi. Nella tua immagine originale sembra che tu abbia 5 lavoratori, il che è raccomandato per un sistema a 4 core, e ognuno usa circa ~ 250 mb di memoria. Non si dovrebbero notare differenze di rendimento se si riduce il numero di lavoratori a 3.

Inoltre, è possibile leggere this doc su come configurare Unicorn. Sicuramente non vuoi che il numero di lavoratori sia inferiore a 2 perché causa problemi durante la modifica dei file nell'interfaccia utente GitLab, come discussed here e disattiva anche la clonazione su HTTPS in base a questa citazione dal documento collegato:

Con un solo operatore Unicorn, solo git su accesso ssh funzionerà perché il git tramite l'accesso HTTP richiede due worker in esecuzione (un worker per ricevere la richiesta utente e un worker per il controllo di autorizzazione).

Infine, le versioni recenti di GitLab sembrano allocare più memoria alla cache del database postgresql. Ti consigliamo di configurare questa proprietà postgresql['shared_buffers'] in /etc/gitlab/gitlab.rb in 1/4 della tua RAM gratuita totale. Vedere René Link's answer di seguito per ulteriori informazioni su questo.

5

2 opzioni Ho trovato la navigazione in gitlab.rb

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

E questo che ha bisogno di comprensione in base al loro avvertimento:

## 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)" 

Questo è dopo le modifiche di configurazione

Memory usage gitlab c

Ancora MODO troppo a mio parere.

+4

L'impostazione di worker_processes su 1 ha avuto l'effetto contrario dei miei commit tramite l'interfaccia utente web per fallire. – Wernight

+0

Non impostare worker_processes su qualsiasi valore inferiore a 2 a partire da GitLab 10.1. https://gitlab.com/gitlab-org/gitlab-ce/issues/18771 – Xunnamius

13

Ho anche avuto problemi con l'elevato consumo di memoria di gitlab.

Nel mio caso ho scoperto che il servizio postgresl usava gran parte della memoria.

Con il servizio Postgres esecuzione 14.5g di 16G dove utilizzato enter image description here

mi sono fermato un servizio gitlab dopo l'altro e ho scoperto che quando mi fermo postgres un sacco di memoria è stata liberata.

enter image description here

Si può provare

gitlab-ctl stop postgresql 

e ricominciare il servizio con

gitlab-ctl start postgresql 

Finalmente ho trovato la seguente configurazione in /etc/gitlab/gitlab.rb

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

Ho appena impostato i buffer condivisi su 256 MB rimuovendo il commento #, perché 256 MB sono sufficienti per me.

postgresql['shared_buffers'] = "256MB" 

ed eseguito gitlab-ctl reconfigure. gitlab-ctl riavvia i servizi interessati e il consumo di memoria è ora molto moderato. enter image description here

Speriamo che questo aiuti qualcun altro.

7

Dal GitLab 9,0, Prometheus è abilitato di default, che ho notato è stata con molta memoria oltre 1,5 GB nel mio caso, questo può essere disabilitato con prometheus_monitoring['enable'] = false