web-dev-qa-db-fra.com

Utilisation élevée de la mémoire pour Gitlab CE

Regardez cette image montrant la consommation de mémoire de gitlab ce. gitlab ce memory consumption

Je n'ai vraiment pas besoin de tous ces travailleurs, sidekiq ou Unicorn ou tous ces démons. C'est sur IDLE. Je veux dire, je l'ai installé pour gérer 1 projet, avec comme 4 personnes, je n'ai pas besoin de tous ces démons. Y a-t-il un moyen de réduire cela?

gitgitlabgitlab-omnibus
28
delmalki

D'après votre image, il semble que Sidekiq et tous ses employés utilisent une somme totale de 257 Mo de mémoire, ce qui est normal. N'oubliez pas que tous les employés de Sidekiq utilisent le même pool de mémoire, ils utilisent donc 257 Mo au total, et non 257 Mo chacun. Comme vous l'avez vu dans votre propre réponse, la diminution du nombre de travailleurs Sidekiq ne diminuera pas considérablement l'utilisation de la mémoire, mais entraînera des travaux en arrière-plan plus longs car ils doivent attendre qu'un processus Sidekiq soit disponible. Je laisserais cette valeur par défaut, mais si vous voulez vraiment la diminuer, je ne la diminuerais pas en dessous de 4 puisque vous avez 4 cœurs.

Les processus Unicorn partagent également un pool de mémoire, mais chaque travailleur a 1 pool qui est partagé entre ses 2 processus. Dans votre image d'origine, il semble que vous ayez 5 employés, ce qui est recommandé pour un système à 4 cœurs, et chacun utilise environ 250 Mo de mémoire. Vous ne devriez pas remarquer de différences de performances si vous diminuez le nombre de travailleurs à 3.

En outre, vous voudrez peut-être lire ce document sur la façon de configurer Unicorn. Vous ne voulez certainement pas que le nombre de travailleurs soit inférieur à 2, car cela provoque des problèmes lors de la modification des fichiers à partir de l'interface utilisateur de GitLab, comme discuté ici , et il désactive également le clonage via HTTPS selon cette citation du document que j'ai lié:

Avec un travailleur Unicorn, seul l'accès git over ssh fonctionnera car l'accès git over HTTP nécessite deux travailleurs en cours d'exécution (un travailleur pour recevoir la demande de l'utilisateur et un travailleur pour le contrôle d'autorisation).

Enfin, les versions récentes de GitLab semblent allouer plus de mémoire au cache de la base de données postgresql. Je recommanderais de configurer cette propriété postgresql['shared_buffers'] dans /etc/gitlab/gitlab.rb soit 1/4 de votre RAM totale libre. Voir réponse de René Link ci-dessous pour plus d'informations à ce sujet.

15
BrokenBinary

J'ai également eu des problèmes avec la consommation élevée de mémoire de gitlab. J'ai donc exécuté l'outil linux htop.

Dans mon cas, j'ai découvert que le service postgresl utilisait la majeure partie de la mémoire.

Avec le service postgres fonctionnant 14,5G de 16G ont été utilisés enter image description here

J'ai arrêté un service gitlab après l'autre et j'ai découvert que lorsque j'arrête postgres beaucoup de mémoire est libérée.

enter image description here

Tu peux l'essayer

gitlab-ctl stop postgresql

et redémarrez le service avec

gitlab-ctl start postgresql

Enfin, je suis tombé sur la configuration suivante dans /etc/gitlab/gitlab.rb

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

Je viens de définir les tampons partagés à 256 Mo en supprimant le commentaire #, car 256 Mo me suffisent.

postgresql['shared_buffers'] = "256MB"

et exécuté gitlab-ctl reconfigure. gitlab-ctl redémarre les services affectés et la consommation de mémoire est désormais très modérée. enter image description here

J'espère que cela aide quelqu'un d'autre.

28
René Link

Depuis GitLab 9.0, prometheus est activé par défaut, ce qui, j'ai remarqué, utilisait beaucoup de mémoire de plus de 1,5 Go dans mon cas, cela peut être désactivé avec prometheus_monitoring['enable'] = false

11
anon

2 Options que j'ai trouvées en parcourant le gitlab.rb

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

Et cela qui nécessite d'être compris selon leur avertissement:

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

C'est après les modifications de configuration

Memory usage gitlab c

Encore beaucoup trop à mon avis.

8
delmalki

J'ai déjà résolu ce cas.
Qui a utilisé le plus de mémoire est la licorne!
La version de mon gitlab était "GitLab Community Edition 10.6.3".
Et il a été déployé sur mon serveur, c'est le processeur, INTEL Core i5 8400 pour six cœurs.
Donc gitlab alloue 7 progressions pour Unicorn, chaque progression occupait 6% mem.

Méthode:
vim /var/opt/gitlab/gitlab-Rails/etc/Unicorn.rb
Comment modifier le fichier Unicorn.rb
Modifier et enregistrer les modifications. Et exécutez "gitlab-ctl restart Unicorn"
Le htop derrière Unicorn.rb change

2
王海吉