почему unicorn?

[zynaps]

Привет.

Не холивара ради, но почему некоторые тут уверенно выбирают unicorn,
когда есть passenger? :)

Если речь не идет про использование нескольких версий руби на одном
сервере, то использование passenger3 в виде модуля nginx со всех
сторон удобнее. И, вообще, вся конструкция тупо проще (нет всяких
bundle exec, monit/bluepill и прочего).

Я использовал unicorn когда passenger был еще 2, а теперь счастлив с
passenger3.

Может я чего-то не знаю? :)

Почему вы используете unicorn?

[a.ognevsky]

Поговаривают, что при деплое нужно перезапускать пассажир, чтобы он «скушал» новый код, а unicorn позволяет этого не делать. Сам с единорогом не работал, из того что читал/слышал.

--

Andrey Ognevsky

--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ

Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror...@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-un...@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru

[Akzhan Abdulin]

 Я использовал Passenger, когда он был версии 2, и был несчастен :)

Потом перешел на unicorn и стал счастливее :)

Из запомнившегося - частые ошибки вида E_PIPE. http://groups.google.com/group/phusion-passenger/browse_thread/thread/6983450304341d89

14 апреля 2011 г. 17:29 пользователь zynaps <zyn...@gmail.com> написал:

[Anton Ageev]

Ну например, passenger всё ещё не позволяет задать для каждого
приложения отдельно максимальное кол-во инстансов. В итоге,
малонагруженное приложение забирает себе столько же инстансов (и
памяти), сколько и сильнонагруженное.

2011/4/14 zynaps <zyn...@gmail.com>:

--
WBR, Anton

[Akzhan Abdulin]

Для Единорога обычно достаточно послать SIG_HUP.

14 апреля 2011 г. 17:32 пользователь a.ognevsky <a.ogn...@gmail.com> написал:

[Akzhan Abdulin]

Еще из запомнившегося - стабильный код, который работает не первый год, под Пассажиром после развертывания стал выпадать с ошибкой вида "не могу найти класс StringIO". Конечно, вылечилось с помощью require 'stringio' где-то в коде (даже не помню, что правил, пассажир или добавил преинициализатор). В общем, меня эти некошерные мелочи напрягали.

14 апреля 2011 г. 17:29 пользователь zynaps <zyn...@gmail.com> написал:

Привет.

[Alexey Kovyrin]

2011/4/14 Anton Ageev <ant...@gmail.com>

Ну например, passenger всё ещё не позволяет задать для каждого
приложения отдельно максимальное кол-во инстансов. В итоге,
малонагруженное приложение забирает себе столько же инстансов (и
памяти), сколько и сильнонагруженное.

Угу, это и есть та самая причина, по которой мы используем unicorn - чтобы запускать всякие мелкие сервисы рядом с большими приложениями.

--

Alexey Kovyrin

http://kovyrin.net/

[Aleksandr Furmanov]

У меня такая же точно история. Быстрее было перейти на уникорн чем разбираться чего там не так с пассажиром. 

[Alex Sergeyev]

Кто-нибудь в итоге ришил проблему, когда пассажир начинает требовать
прописывание в require всего что используется? Я недавно наткнулся и ,
в итоге тоже забил и перешел на unicorn.

2011/4/15 Aleksandr Furmanov <aleksandr...@gmail.com>:

--
Alex Sergeyev

[funny_falcon]

Видимо другим серверам нужно тоже, что и вам, и они делают для себя
require того, что вам нужно. А passenger даёт вам более чистое
окружение. Из этого следует вывод, что ошибка скорее у вас, чем у
пасажира.

On 15 апр, 11:36, Alex Sergeyev <alex.serge...@gmail.com> wrote:
> Кто-нибудь в итоге ришил проблему, когда пассажир начинает требовать
> прописывание в require всего что используется? Я недавно наткнулся и ,
> в итоге тоже забил и перешел на unicorn.
>

> 2011/4/15 Aleksandr Furmanov <aleksandr.furma...@gmail.com>:

>
>
>
>
>
>
>
>
>
> > У меня такая же точно история. Быстрее было перейти на уникорн чем
> > разбираться чего там не так с пассажиром.
> > On Apr 14, 2011, at 6:51 AM, Akzhan Abdulin wrote:
>
> >  Я использовал Passenger, когда он был версии 2, и был несчастен :)
> > Потом перешел на unicorn и стал счастливее :)
> > Из запомнившегося - частые ошибки вида

> > E_PIPE. http://groups.google.com/group/phusion-passenger/browse_thread/thread...

[Mikhail Lapshin]

Может я не так понимаю смысл конфигурационных директив passenger-a, но
вроде бы с помощью passenger_max_pool_size и passenger_min_instances в
блоках server (в случае с nginx) можно каждому приложению нужное
кол-во инстасов задать.

2011/4/14 Anton Ageev <ant...@gmail.com>:

[Alex Sergeyev]

2011/4/15 funny_falcon <funny....@gmail.com>:

> Видимо другим серверам нужно тоже, что и вам, и они делают для себя
> require того, что вам нужно. А passenger даёт вам более чистое
> окружение. Из этого следует вывод, что ошибка скорее у вас, чем у
> пасажира.

Да, вопрос только в том, почему до перехода на бандлер это все
работало, а так же работало на всем что я еще пробовал (thin, unicorn,
webrick)
Я не спорю, возможно нужно писать руками require для всего, но вроде
как config.gem и затем bundler и используется для того, чтобы этого не
делать.

Мне кажется, наоборот, что в пассажире слишком много всякой магии,
которая иногда перестает работать.

[Anton Ageev]

2011/4/15 Mikhail Lapshin <sota...@sotakone.com>:

> Может я не так понимаю смысл конфигурационных директив passenger-a, но
> вроде бы с помощью passenger_max_pool_size и passenger_min_instances в
> блоках server (в случае с nginx) можно каждому приложению нужное
> кол-во инстасов задать.

Выдержка из документации по passenger_max_pool_size:
...
This option may only occur once, in the http configuration bock.
...

[Alex L. Demidov]

On Thu, Apr 14, 2011 at 06:29:53AM -0700, zynaps wrote:
> Привет.
>
> Не холивара ради, но почему некоторые тут уверенно выбирают unicorn,
> когда есть passenger? :)
>
> Если речь не идет про использование нескольких версий руби на одном
> сервере, то использование passenger3 в виде модуля nginx со всех
> сторон удобнее. И, вообще, вся конструкция тупо проще (нет всяких
> bundle exec, monit/bluepill и прочего).

Это так снаружи кажется что проще. На самом деле passenger запускает
еще большую пачку разнообразных процессов нежели нужно для связки
nginx+unicorn.

Там присутствует и свой http proxy, который делает forward запросов
от apache/nginx к воркерам (которые слушают на 127.0.0.1), и свой
watchdog, который выполняет функции daemontools/runit, свой
application spawner - аналог unicorn master process и еще framework
spawner в случае smart spawn method, плюс ко всему некие helper
agent и logging agent.

Большая часть этих процессов динамически стартует и останавливается
в зависимости от нагрузки и таймаутов, что создает проблему номер
один - при наплыве трафика после периода простоя нужно запускать
новых воркеров, что для rails есть достаточно тяжелая операция. Ее
решают путем использования хитрых методов создания воркеров (smart и
smart-lv2 spawn methods), который используют вышеупомянутые
application/framework spawner'ы для fork'а воркеров что позволяет
сократить время старта воркера и, в случае использования REE,
потребление памяти за счет CoW. В unicorn все воркеры запускаются
при старте, при этом присутствует опция preload_app которая
аналогична smart spawn и позволяет экономить память в случае REE.

Хитрые способы создания воркеров создают проблему номер два - file
descriptor sharing между процессами и в случае использования
smart-lv2 spawn method - проблемы с code load order. В unicorn из
этих проблем присутствует только sharing FD в случае если включен
preload_app.

Проблема номер три - в отличии от unicorn и несмотря на наличие в
passenger отдельного watchdog процесса, зависший в вечном цикле
воркер никак не отслеживается и будет висеть до скончания века. Так
же нет классической апачевской опции ограничить количество requests
per worker для борьбы с memory leaks (но этого нет и в unicorn).

Проблема номер четыре - для разбрасывания запросов между воркерами
passenger использует очереди - либо индивидуальные, per worker, либо
одну глобальную, в зависимости от настроек. В случае индивидуальных
очередей возникает проблема что если какой-то воркер задумался,
обрабатывая долгий запрос, то все запросы уже попавшие в его очередь
будут висеть, даже если остальные воркеры свободны. Эту проблему
решает использование глобальной очереди, но она имеет свойство
залипать на FreeBSD. В unicorn передача запросов делается через
обычный сокет и проблемы приоритезации лежат целиком на ядре.

Общее впечатление - у passenger'а ниже порог вхождения и запустить
rails приложение под ним первый раз намного проще. При этом есть
смысл использовать его в ситуации когда один сервер обслуживает
несколько слабонагруженных приложений с спорадическими всплесками
трафика, с целью экономии ресурсов.

Для более же серьезных приложений, когда нагрузка более менее
постоянная и нужно не выжимать максимум из минимума, а наоборот, при
экстремальной нагрузке обеспечить graceful degradation сервиса, то
здесь nginx+unicorn мне видится более простой, более прозрачной и
более управляемой конструкцией.

>
> Я использовал unicorn когда passenger был еще 2, а теперь счастлив с
> passenger3.
>
> Может я чего-то не знаю? :)
>
> Почему вы используете unicorn?

--
Alex L. Demidov (ALD9-RIPE).
http://alexeydemidov.com/
Freelance Consulting.

[Oleh Khomey]

Это есть – PassengerMaxRequests

Regards,
  Oleh Khomey

2011/4/17 Alex L. Demidov <alexey...@gmail.com>

[Max Lapshin]

Я может чего-то пропустил: а в passenger есть _действительно_
zero-downtime deploy, когда новый код либо запускается и работает без
потери единого запроса, либо не запускается?

[Alexander Simonov]

так и в уникорне это есть.
при деплое делаем релоад и запускается новый мастер, как при бинари апдейте nginx.

Alexander Simonov
asim...@gmail.com

[Max Lapshin]

2011/4/18 Alexander Simonov <asim...@gmail.com>:

> так и в уникорне это есть.
> при деплое делаем релоад и запускается новый мастер, как при бинари апдейте nginx.
>

В юникорне есть. Я не помню, есть ли это в passenger

[a.ognevsky]

Во втором точно не было, я было думал, что все с него на единорога именно поэтому и убегают. Как показал этот тред, я ошибался.

--

Andrey Ognevsky

[Alex L. Demidov]

В Passenger 3 заявлена возможность пережить apachectl restart с zero
downtime, но по словам Phusion CTO [1] это только для ситуации когда
нужно поменять конфиг apache. Для деплоя приложения они планируют
т.н. Rolling applications restart который будет доступен в платной
Premium версии Phusion Passenger [2], [3], [4].

[1] http://blog.phusion.nl/2010/06/18/the-road-to-passenger-3-technology-preview-2-stability-robustness-availability-self-healing/comment-page-1/#comment-22181
[2] http://groups.google.com/group/phusion-passenger/browse_thread/thread/23ef0cf314115609
[3] http://groups.google.com/group/phusion-passenger/browse_thread/thread/b99589023f886464/9f2d5ff319782b1e
[4] http://groups.google.com/group/phusion-passenger/browse_thread/thread/efc278478ba4d299/364897fecb6d192a

On Sun, Apr 17, 2011 at 11:28:11PM +0200, a.ognevsky wrote:
> Во втором точно не было, я было думал, что все с него на единорога
> именно поэтому и убегают. Как показал этот тред, я ошибался.
>
> --
> Andrey Ognevsky
>
> On Sunday, April 17, 2011 at 11:24 PM, Max Lapshin wrote:
> > 2011/4/18 Alexander Simonov <asim...@gmail.com>:
> > > так и в уникорне это есть.
> > > при деплое делаем релоад и запускается новый мастер, как при бинари апдейте nginx.
> >
> >
> > В юникорне есть. Я не помню, есть ли это в passenger
> >

--

[Alex L. Demidov]

On Sun, Apr 17, 2011 at 10:57:26PM +0300, Oleh Khomey wrote:
> Это есть - PassengerMaxRequests

Виноват, пропустил что такая опция есть для Passenger Apache. В
документации на nginx Passenger такой опции или чего-то подобного я
не нашел.

> 2011/4/17 Alex L. Demidov <alexey...@gmail.com>
>
> > Так же нет классической апачевской опции ограничить количество
> > requests per worker для борьбы с memory leaks
> >

--

[Mikhail Lapshin]

2011/4/15 Anton Ageev <ant...@gmail.com>:

> 2011/4/15 Mikhail Lapshin <sota...@sotakone.com>:
>> Может я не так понимаю смысл конфигурационных директив passenger-a, но
>> вроде бы с помощью passenger_max_pool_size и passenger_min_instances в
>> блоках server (в случае с nginx) можно каждому приложению нужное
>> кол-во инстасов задать.
>
> Выдержка из документации по passenger_max_pool_size:
> ...
> This option may only occur once, in the http configuration bock.

Ну да. Предположим, тебе нужно 4 инстанса на первое приложение, и 1
инстанс на второе. Делаешь max_pool_size = 5, а в блоках server
устанавшиваешь min_instances в 4 и 1, соответственно.

> ...
>
>> 2011/4/14 Anton Ageev <ant...@gmail.com>:
>>> Ну например, passenger всё ещё не позволяет задать для каждого
>>> приложения отдельно максимальное кол-во инстансов. В итоге,
>>> малонагруженное приложение забирает себе столько же инстансов (и
>>> памяти), сколько и сильнонагруженное.
>>>
>>> 2011/4/14 zynaps <zyn...@gmail.com>:
>>>> Привет.
>>>>
>>>> Не холивара ради, но почему некоторые тут уверенно выбирают unicorn,
>>>> когда есть passenger? :)
>>>>
>>>> Если речь не идет про использование нескольких версий руби на одном
>>>> сервере, то использование passenger3 в виде модуля nginx со всех
>>>> сторон удобнее. И, вообще, вся конструкция тупо проще (нет всяких
>>>> bundle exec, monit/bluepill и прочего).
>>>>
>>>> Я использовал unicorn когда passenger был еще 2, а теперь счастлив с
>>>> passenger3.
>>>>
>>>> Может я чего-то не знаю? :)
>>>>
>>>> Почему вы используете unicorn?
>
> --
> WBR, Anton
>

[Phil Pirozhkov (pirj)]

А смысл? Метод "две ноды за балансировщиком нагрузки, и их
перезагрузка по очереди" уже не работает?

On Apr 18, 11:11 am, "Alex L. Demidov" <alexeydemi...@gmail.com>
wrote:

> В Passenger 3 заявлена возможность пережить apachectl restart с zero
> downtime, но по словам Phusion CTO [1] это только для ситуации когда
> нужно поменять конфиг apache. Для деплоя приложения они планируют
> т.н. Rolling applications restart который будет доступен в платной
> Premium версии Phusion Passenger [2], [3], [4].
>

> [1]http://blog.phusion.nl/2010/06/18/the-road-to-passenger-3-technology-...
> [2]http://groups.google.com/group/phusion-passenger/browse_thread/thread...
> [3]http://groups.google.com/group/phusion-passenger/browse_thread/thread...
> [4]http://groups.google.com/group/phusion-passenger/browse_thread/thread...

>
> On Sun, Apr 17, 2011 at 11:28:11PM +0200, a.ognevsky wrote:
> > Во втором точно не было, я было думал, что все с него на единорога
> > именно поэтому и убегают. Как показал этот тред, я ошибался.
>
> > --
> > Andrey Ognevsky
>
> > On Sunday, April 17, 2011 at 11:24 PM, Max Lapshin wrote:

> > > 2011/4/18 Alexander Simonov <asimo...@gmail.com>:

[Alex L. Demidov]

On Mon, Apr 18, 2011 at 02:18:18PM +0400, Mikhail Lapshin wrote:
> 2011/4/15 Anton Ageev <ant...@gmail.com>:
> > 2011/4/15 Mikhail Lapshin <sota...@sotakone.com>:
> >> Может я не так понимаю смысл конфигурационных директив passenger-a, но
> >> вроде бы с помощью passenger_max_pool_size и passenger_min_instances в
> >> блоках server (в случае с nginx) можно каждому приложению нужное
> >> кол-во инстасов задать.
> >
> > Выдержка из документации по passenger_max_pool_size:
> > ...
> > This option may only occur once, in the http configuration bock.
>
> Ну да. Предположим, тебе нужно 4 инстанса на первое приложение, и 1
> инстанс на второе. Делаешь max_pool_size = 5, а в блоках server
> устанавшиваешь min_instances в 4 и 1, соответственно.

Здесь есть один нюанс. Несмотря на ненулевые значения в
min_instances passenger все равно не запускает эти instance сразу
при старте, а ждет обращений к этим приложениям. Поэтому
рекомендуется совместно с min_instance использовать директиву
passenger_pre_start или в противном случае первый запрос к
приложению будет долго висеть ожидая spawn приложения passenger'ом.

[Alex L. Demidov]

On Mon, Apr 18, 2011 at 11:20:47AM -0700, Phil Pirozhkov (pirj) wrote:
> А смысл? Метод "две ноды за балансировщиком нагрузки, и их
> перезагрузка по очереди" уже не работает?

Не работает если суммарная нагрузка больше чем может обработать одна
нода.

> --
> --
> Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
> FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
>
> Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
> ror...@googlegroups.com
> Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-un...@googlegroups.com
> Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru

--

[northbear]

Меня в unicorn откровенно подкупило отсутствие необходимости в
Аrchlinux'е пересобирать nginx для нормальной работы в связке.
В случае с passenger'ом переход на более свежий nginx требует прямого
вмешательства и деплой перестает быть автоматическим.

В связи с этим не очень понятно почему тут выше решили порог входа при
использовании passenger ниже чем unicorn.

[a.ognevsky]

Я озвучу про порог входа. Мне очевидно, что для установки пассажира (и nginx'a) нужно написать:

gem install passenger

install_passenger_nginx_module, он автоматом поставит nginx, настроит его для работы и, кажется, даже запустит. Мне останется прописать туда свое приложение — и вперед. И уже потоооом, когдааа-нибудь, мне наверняка нужно будет исправить настройки, но при этом приложение будет работать.

Плюсом к пассажиру есть официальный скринкаст «для блондинок». Как поставить и настроить unicorn я, например, не знаю. Ну, понятно что поставить гем и написать unicorn_rails, но это немного не то, что я хочу, например. Как это сделать правильно, чтобы все работало как в пассажире, я лично не знаю. Был бы признателен любой информации по этому поводу, кстати.

--

Andrey Ognevsky

[northbear]

Дык... RTFM. Вы же как-то узнали про install_passenger_nginx_module и
про скринкаст для блондинок.
Тупо в Google поиск 'nginx unicorn'. Куча примеров достаточно
тривиального конфига nginx. А все остальное крутится в unicorn по мере
надобности.

On 19 апр, 20:37, "a.ognevsky" <a.ognev...@gmail.com> wrote:
> Я озвучу про порог входа. Мне очевидно, что для установки пассажира (и nginx'a) нужно написать:
> gem install passenger

> install_passenger_nginx_module, он автоматом поставит nginx, настроит его для работы и, кажется, даже запустит. Мне останется прописать туда свое приложение -- и вперед. И уже потоооом, когдааа-нибудь, мне наверняка нужно будет исправить настройки, но при этом приложение будет работать.