Высокое использование памяти для Gitlab CE

Судя по вашему изображению, Sidekiq и все его рабочие используют в общей сложности 257 МБ памяти, что нормально. Помните, что все рабочие Sidekiq используют один и тот же пул памяти, поэтому они используют всего 257 МБ, а не по 257 МБ каждый. Как вы видели из своего собственного ответа, уменьшение количества рабочих Sidekiq не приведет к резкому уменьшению использования памяти, но приведет к тому, что фоновые задания будут занимать больше времени, поскольку им придется ждать, пока процесс Sidekiq станет доступным. Я бы оставил это значение по умолчанию, но если вы действительно хотите его уменьшить, я бы не стал уменьшать его ниже 4, поскольку у вас 4 ядра.

Процессы Unicorn также совместно используют пул памяти, но у каждого рабочего есть 1 пул, который совместно используется двумя его процессами. В вашем исходном образе у вас есть 5 рабочих процессов, что рекомендуется для 4-ядерной системы, и каждый использует около 250 МБ памяти. Вы не заметите разницы в производительности, если уменьшите количество рабочих до 3.

Кроме того, вы можете прочитать этот документ о том, как настроить Unicorn. Вы определенно не хотите, чтобы количество рабочих процессов было меньше 2, потому что это вызывает проблемы при редактировании файлов из пользовательского интерфейса GitLab, как обсуждается здесь, а также отключает клонирование через HTTPS в соответствии с этой цитатой из документа, на который я дал ссылку:

С одним воркером Unicorn будет работать только доступ git через ssh, потому что доступ git через HTTP требует двух работающих воркеров (один воркер для получения запроса пользователя и один воркер для проверки авторизации).

Наконец, последние версии GitLab, кажется, выделяют больше памяти для кеша базы данных postgresql. Я бы рекомендовал настроить это свойство postgresql['shared_buffers'] в /etc/gitlab/gitlab.rb так, чтобы оно составляло 1/4 от общего объема свободной оперативной памяти. См. ответ Рене Линка ниже для получения дополнительной информации об этом.

У меня также были проблемы с высоким потреблением памяти gitlab. Итак, я запустил инструмент Linux htop.

В моем случае я обнаружил, что служба postgresl использует большую часть памяти.

При работе службы postgres было использовано 14,5 ГБ из 16 ГБ

Я останавливал одну службу gitlab за другой и обнаружил, что когда я останавливаю postgres, освобождается много памяти.

Можешь попробовать

gitlab-ctl stop postgresql

и снова запустите службу с помощью

gitlab-ctl start postgresql

Наконец я наткнулся на следующую конфигурацию в /etc/gitlab/gitlab.rb

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

Я просто установил общие буферы на 256 МБ, удалив комментарий #, потому что 256 МБ мне достаточно.

postgresql['shared_buffers'] = "256MB"

и выполнил gitlab-ctl reconfigure. gitlab-ctl перезапускает затронутые службы, и потребление памяти теперь очень умеренное.

Надеюсь, это поможет кому-то еще.

Начиная с GitLab 9.0, prometheus включен по умолчанию, что, как я заметил, в моем случае использовало много памяти более 1,5 ГБ, это можно отключить с помощью prometheus_monitoring['enable'] = false

2 варианта, которые я нашел, просматривая gitlab.rb

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

И то, что требует понимания согласно их предупреждению:

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

Это после модификации конфига

Все еще слишком много, на мой взгляд.

Я уже исправил этот случай.
Больше всего памяти использовал единорог!
Моя версия gitlab была "GitLab Community Edition 10.6.3".
И она была развернута на моем сервере, это cpu , INTEL Core i5 8400 на шесть ядер.
Итак, gitlab выделил 7 прогрессов для единорога, каждый прогресс занимал 6% памяти.

Метод:
vim /var/opt/gitlab/gitlab-rails/etc/unicorn.rb
Как редактировать файл unicorn.rb
Редактировать и сохранить изменения. И выполните "gitlab-ctl restart unicorn"
Htop за изменениями unicorn.rb

У меня была та же проблема: ванильный Gitlab на ванильном Ubuntu 20.04 проработал, может быть, день, прежде чем вылететь без какой-либо нагрузки. EPYC на голом железе, 8c/16t и 64 ГБ оперативной памяти.

Postgresql брал свою долю 15G, как упоминалось в BrokenBinary answer, но даже исправить это до 2G было недостаточно.

Мне также пришлось исправить количество рабочих Puma:

puma['worker_processes'] = 2

Похоже, что в более новых установках Gitlab будут утечки памяти при использовании замены unicorn, у которой были утечки памяти.

Обновление: снова произошел сбой. Следующая попытка:

sidekiq['max_concurrency'] = 6
sidekiq['min_concurrency'] = 2

Когда я изменил /etc/gitlab/gitlab.rb, как упоминалось в других ответах, у меня это не сработало.

Вот что я сделал, я отредактировал следующий файл:

/var/opt/gitlab/gitlab-rails/etc/unicorn.rb (Возможно, путь к файлу в вашей машине другой)

И изменил worker_processes 9 на worker_processes 2.