Как оптимизировать процессы Unicorn в Ruby on Rails приложении

[mrThe]

А мы перешли на puma и забыли unicorn как страшный сон.

[rsludge]

вы используете Пуму на MRI? Расскажите про преимущества по сравнению с unicorn, с какими трудностями столкнулись при переходе?

[mrThe]

Когда в последний раз тестировал: при 8 потоках пума использовала в 10 раз меньше памяти чем юникорн (при тех же 8 потоках) и обрабатывала в полтора раза больше запросов.
Тестировал на амазоновском сервере с помощью ab, уже не помню конфигурацию, было что-то около 4-х ядер и 4гб памяти.
Трудностей вообще никаких, конфигурируется она сильно проще чем юникорн.

[Bonch]

Я не в курсе, но может вы знаете ответ. Вот у юникорна при деплое воркеры заменяются на новые постепенно, в итоге, сайт непрерывно продолжает работать. А у puma с этим как? Там есть такое, или ставится заглушка, что сайт обновляется?

[le0pard]

У puma это есть, но вот стабильностью «phased-restart» похвастаться пока не может. Самый частый случай — пришел новый гем и puma просто падает при сигнале рестарта :)

[le0pard]

Тут кстати логичный вопрос. У уникорна нет потоков, только воркеры, в то время как у пумы — потоки + кластер режим, что означает тоже самое, что и у юникорна. Тоесть вы сравнивали производительность 8 workers unicorns vs 8 puma cluster mode без тредов внутри каждого? Поскольку только так тестирование будет приближено к реальности тестирования самого веб сервера. Ведь puma выиграет, поскольку из коробки один демон создает 16 тредов, что уже дает фору (но и создает проблемы в MRI).

[reiser]

zero downtime restart?

Ну и в nginx'е нужно писать всего одну строчку на все воркеры юникорна, а не по одной на каждой :)

[le0pard]

Nginx:

upstream prodpuma {
  server unix:/.../shared/tmp/sockets/puma.sock fail_timeout=0;
}

Puma:

bind 'unix:///.../shared/tmp/sockets/puma.sock'
state_path '/.../shared/tmp/sockets/puma.state'

Zero downtime:

desc 'Restart puma (phased restart)'
task :phased_restart, :roles => lambda { puma_role }, :on_no_matching_servers => :continue do
  run "cd #{current_path} && #{pumactl_cmd} -S #{state_path} phased-restart"
end

[reiser]

Ну я thin'ом сравнивал, puma не пробовал пока

[le0pard]

Да, кстати, если уж и сравнивать, то unicorn и rainbows!, то последний основан на первом. Основное отличие — разные задачи использования. Задача unicorn — обслуживание быстрых запросов, в то время как для rainbows! — долго «живучих» запросов. Поэтому первый хорош для простых сайтов с запрос-ответ (тоесть почти для всех веб сайтов), а второй для обслуживание websocket или commet соединений.

[AlexeiZhuravlev]

Использую связку 1 Nginx + 20 Thin. Версия руби 1.8.7 и вполне доволен скорость работы. Памяти используется очень мало.

Unicorn устанавливал один раз. После его запуска был поражен сколько памяти он «съел» по сравнению с Thin. Автору может быть присмотреться к другим веб-серверам? Чем уж так хорош Unicorn? Или просто лень переучиваться?

[le0pard]

Это ж как вы забили на технический долг, раз используете 1.8.7, на который уже даже security обновления не выходят :)

[AlexeiZhuravlev]

Вы не правы.
Цитирую новость с официального сайта Руби:

Новость от 17 декабря 2013 года — версии Ruby 1.8.7 и 1.9.2 будут поддерживаться патчами для безопасности до июня 2014 г.

[le0pard]

Ну главное что бы этого времени хватило мигрировать.

[ka8725]

А почему passenger не обсуждается в комментариях?

[Yanzay]

А что вы хотите обсудить по поводу passenger'а?

[ka8725]

Например, почему бы его не использовать в продакшене как альтернативу вышеупомянутым thin, unicorn и недоделанном puma?

[slaykovsky]

А почему puma вдруг недоделанный?

[seriyPS]

Т.к. созданные (форкнутые) процессы являются копиями друг друга, это значит, что rails-приложение должно быть потокобезопасным.

Неправда.

[le0pard]

Подтверждаю. Форк и тред — это разные вещи.

[le0pard]

Странно, но мы всегда находили и исправляли утечку памяти. Вариант unicorn-worker-killer уже если вообще команда не может с этим справится (хотя мы monit для этого использовали, что бы следить за памятью — он сразу и писал письмо, что воркер пришлось перегрузить). Но это точно не решает проблему с утечками.

[rsludge]

кроме утечек есть же еще и bloating

[le0pard]

Это не поводу убивать процесс — там может выполнятся важная задача (например, идет работа с платежом от клиента). Если все написано без особой магии, то Ruby GC почистить обьекты и память вернется на место.