Comments 15
рабочий процесс обработал всего 23 запроса
Всё же, он обработал не всего 23 запроса, а вообще работал 23 секунды, за которые мог успеть обработать запросов гораздо больше. Если бы какое либо приложение на моем сервере бы рестартилось каждые 23 запроса (пусть и без разрывов связи) — я бы снёс такое приложение не задумываясь.
Мой GitLab живёт по 3-4 часа на воркер и обрабатывает несколько сотен тысяч запросов за это время.
Я извиняюсь, а какие такие религиозные причины мешают просто взять и починить memory leak'и?
Я вот честно сказать тоже не понимаю. Везде где вижу упоминания про этот unicorn — везде пишут про проблемы с памятью, но при этом продолжают пользоваться. Мыши кололись но продолжали жрать кактус? Вместо того чтоб починить иточник проблемы — придумали костыли, которые решают проблему с памятью за счёт нагрузки на ЦП.
Вероятно, это не так уж и просто. Не думаю, что просто так вот взяли и не починили.
Ruby?
Пытались и неоднократно, как они пишут. Исправить не получилось до их пор, поэтому костыль.
Зачем еще один перевод? Еще остались пользователи юникорна, которые не знают про worker-killer? Нового ничего они не предлагают. Если пропустить через s/gitlab/other-unicorn-user/g, то всё так же останется правдой.
Это не unicorn, это руби.Gitalab CE нельзя запустить на 5$ DO instance потому что не влазит в память при загрузке (конечно можно своп но сервер свопящийся уже на старте это грустно)
Sign up to leave a comment.
Перевод: как gitLab использует unicorn и unicorn-worker-killer