Единорог GitLab Series 3

GitLab

Зачем GitLab нужен Unicorn

В прошлый раз мы в основном объяснялиФункционал смарт-прокси для компонента GitLab-workhorse, с этого момента мы начнем вводить самые основные и самые сложные компоненты:Unicorn(GitLab Rails), я также говорил в прошлый раз, что этот компонент в основном имеет дело с динамическими веб-страницами и API-интерфейсами.


В этой статье впервые представлена ​​роль Единорога, уже одно это может рассказать о многом.


Unicorn — это веб-сервер Ruby, который использует модель с несколькими процессами и следует протоколу Rack. Если вы хотите сравнить стек технологии веб-разработки Java, приложение Rails эквивалентно приложению Spring MVC framework, веб-сервер Unicorn эквивалентен tomcat

Приложение GitLab Rails (то есть gitlab-ce) работает внутри сервера Unicorn, и причины использования Unicorn следующие:Unicorn может предоставить приложениям Rails возможность одновременной обработки клиентских запросов и обеспечить более высокую отказоустойчивость.

Многопроцессорная модель Unicorn может эффективно использовать ресурсы многоядерного ЦП сервера для обеспечения лучших возможностей параллелизма. Когда Unicorn запускается, основной процесс Unicorn, главный процесс, создаст ряд рабочих процессов в виде ветвления.Unicorn управляет несколькими рабочими процессами через главный процесс, где главный процесс не отвечает за обработку HTTP-запросов от клиентов, а несколько рабочих процессов прослушивают один и тот же набор сокетов для обработки клиентских запросов.


На самом деле, рабочий процесс может зависнуть или истечь время ожидания (тайм-аут означает, что если главный процесс обнаружит, что рабочий процесс слишком долго обрабатывает запрос, главный процесс отправит сигнал (SIGKILL, kill -9) для завершения рабочего процесса. обработать)

# unicorn_stderr.log 日志，以下表示id 为 10 的 worker 的进程超时，master 进程杀掉后又重启了新进程，重启前后 pid 是不一致的
[2015-06-05T10:58:08.660325 #56227] ERROR -- : worker=10 PID:53009 timeout (61s > 60s), killing
[2015-06-05T10:58:08.699360 #56227] ERROR -- : reaped #<Process::Status: pid 53009 SIGKILL (signal 9)> worker=10
[2015-06-05T10:58:08.708141 #62538]  INFO -- : worker=10 spawned pid=62538
[2015-06-05T10:58:08.708824 #62538]  INFO -- : worker=10 ready

Независимо от того, каким образом рабочий процесс будет завершен, главный процесс всегда будет создавать новый рабочий процесс для замены исходного рабочего процесса, и весь процесс не будет отбрасывать запрос пользователя.

gitlab-ce само по себе является приложением с утечкой памяти. Поскольку Unicorn будет разветвлять большое количество рабочих процессов во время выполнения, утечки памяти будут возникать в долго выполняющихся процессах, таких как рабочие процессы (главный процесс почти не имеет утечек памяти, потому что он не часто обрабатывает запросы пользователей). В самом Unicorn не предусмотрена функция автоматического перезапуска рабочего процесса.Для решения этой проблемы появился unicorn-worker-killer.Подробнее см.GitHub.com/extensioncards/unicorn…

GitLab использует unicorn-worker-killer, чтобы держать под контролем утечки памяти этих процессов: рабочий процесс Unicorn будет выполнять самопроверку памяти после каждых 16 запросов.Если размер памяти, занимаемой рабочим процессом, превышает заданное значение, Unicorn Главный процесс автоматически заменит этот рабочий процесс, и весь процесс не повлияет на обработку каких-либо запросов.

# unicorn_stderr.log 日志，以下表示 worker 进程的当前占有内存超过约 250M，于是对此 worker 进程执行重启替换的操作
[2015-06-05T12:07:41.828374 #125918]  WARN -- : #<Unicorn::HttpServer:0x00000002734770>: worker (pid: 125918) exceeds memory limit (256413696 bytes > 254802235 bytes)
[2015-06-05T12:07:41.828472 #125918]  WARN -- : Unicorn::WorkerKiller send SIGQUIT (pid: 125918) alive: 23 sec (trial 1)
[2015-06-05T12:07:42.025916 #117565]  INFO -- : reaped #<Process::Status: pid 125918 exit 0> worker=4
[2015-06-05T12:07:42.034527 #127549]  INFO -- : worker=4 spawned pid=127549
[2015-06-05T12:07:42.035217 #127549]  INFO -- : worker=4 ready

Таким образом, GitLab использует Unicorn для:

  1. Воспользуйтесь преимуществами многоядерных процессоров сервера для одновременной обработки клиентских запросов.
  2. Доступность: исключение одного процесса не приведет к сбою всего приложения GitLab;
  3. Управление утечками памяти в приложениях Rails

Конечно, это также приносит некоторые проблемы:

  1. При использовании нескольких процессов приходится сталкиваться с проблемой поедания памяти, и в то же время количество рабочих процессов в unicorn ограничено.
  2. Блокирующий ввод-вывод с несколькими процессами трудно принять потерю производительности, вызванную медленными клиентами (представьте, что все рабочие процессы обрабатывают медленных клиентов, если клиент все еще медленно читает ответную информацию, подготовленную рабочим процессом, тогда рабочий процесс не будет метод для обработки следующего запроса), поэтому в целом для решения проблемы медленного клиента можно использовать обратный прокси-сервер (например, сервер nginx, или gitlab-workhorse и т. д.) (рабочий процесс отправляет обработанное ответное сообщение на обратный прокси-сервер для области буферизации, обратный прокси-сервер продолжает медленно запутываться с клиентом, и продолжает сам обрабатывать следующий запрос, так что пропускная способность Unicorn естественно не пострадает)


  3. Дизайн Unicorn несовместим с бизнесом GitLab git-over-http/https, который получает доступ к репозиториям Git через HTTP/HTTPS (git clone/push и т. д.). git-over-http/https сам по себе является относительно трудоемкой операцией, и серверу-единорогу явно нецелесообразно увеличивать параметр тайм-аута запроса в угоду этому делу.

приложение

Ссылка на ссылку




Категории