Re: php-fpm upstream pool

["igor.goncharenko" <nginx-forum@xxxxxxxx>]

Maxim Dounin Wrote:
-------------------------------------------------------
> Hello!
> 
> On Fri, Dec 02, 2011 at 03:47:31AM -0500, igor.goncharenko wrote:
>
> > > http://trac.nginx.org/nginx/ticket/64
> > 
> > Да. Очень похоже это оно. Тогда в
продакшин двигать на 1.0.X нельзя пока :(
> 
> Баг потенциально может проявится
тогда и только тогда, когда более 
> одного бекенда в пуле - мёртвые.  И
почти не имеет шансов проявится, если
при этом
> более одного живого бекенда.

А, интересно, что случается если мы
имеем всего 2 бэкенда. Неработающий
один считается больше одного или нет? :)
 
> При этом мёртвый бекенд в пуле - это,
вообще говоря,
> чрезвычайная  ситуация.

Вот-вот, и пока я иду чинить мертвый
бэкенд(ы), я должен быть уверен что nginx
работает с живыми.
 
> [...]
> 
> > на эту ветку и сейчас вроде как время
> > пришло, но появилась задача с fcgi
пулом.
> > И теперь оказалось, похоже, смысла
> > мигрировать на 1.0.X нет - потому что
для
> > задач балансера этот баг - серьезный.
> 
> В 0.8.x в этом месте те же проблемы, и
существенно
> хуже в других  местах.

Никто не меняет продукт в продакшине на
новую версию только потому что он
существенно лучше в каких-то местах. Я
например, меняю только:
a) если я наступил на баги которые были
починены в новой ветке
б) если таковых нет - раз в год или в два
на новую стабл ветку, чтобы не
отставать от жизни

Некоторые вообще не трогают если
работает, opennet например, вообще на 0.6,
если не врут в хеадерах.


> > Насчет 1.1.X. Ну во-первых, ветка
позиционируется как девелопмент,
соответственно, использовать на
> > продакшине можно только в крайнем
случае.
> 
> Отличие stable состоит в  первую очередь
в том, что её, по возможности, не ломают,
т.е. обновления с версии на
> версию не  должны приносить сюрпризов.
 В development нужно быть несколько 
осторожнее с обновлениями (желательно
читать changelog).

changelog читается всегда независимо от
ветки.


> По стабильности - 1.1.10 сейчас лучше, чем
1.0.10.

Хорошо, убедили, может тогда есть смысл
перевести 1.1.X в стейбл, если она по
стабильности лучше и фич уже добалено
много за полгода?

> > Во-вторых, упомянутый вами вопрос с
долгими  запросами. У меня
> > могут быть тяжелые запросы к базе,
надо подумать как изменение в схеме
> > балансинга может на них повлять -
судя по всему тем, что "живые"
> бэкенды будут нагружены больше чем
раньше.
> 
> Если вас это пугает - то зачем вы
просите сделать merge этого 
> изменения в stable? :)

Больше не буду :)

> На самом деле там всё не очень страшно.
  Алгоритм такой: упавший 
> бекенд не будет призна снова
работающим, пока не отработает 
> успешно хотя бы один запрос, на него
отправленный.  Запросы на 
> него будут отправляться 1 раз в
fail_timeout.
> 
> Если запросы долгие (много длиннее
fail_timeout, т.е. не просто 
> "тяжёлые запросы к базе", какой-нибудь
streaming или long 
> polling) это, потенциально, может привести
к тому, что бекенд 
> (после смерти и оживания обратно)
некоторое время будет продолжать 
> считаться мёртвым (пока хотя бы один
запрос не завершится, или  клиент его не
закроет). 
> Нагрузка, соответственно, будет идти 
большей частью на другие
> бекенды.
>
> Есть, впрочем, мнение, что для streaming/long
polling подобное  поведение тоже вполне
> разумно, и максимум что в подобных
ситуациях  следует сделать - это
> уменьшить fail_timeout.

Все логично, спасибо за разъяснение.
 
> > Я бы сделал изменение  схемы
> > балансировки в 1.0.x опциональным и
> > выключенным по дефолту, если это
> > возможно.
> Нет.

Ну, попробовать я должен был :)
 
> 
> Maxim Dounin
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


PS. Тут развели холивар по поводу haproxy и
alive чеков. Как человек, пользующийся
haproxy тоже (как tcp балансировщик), скажу,
что от таких чеков больше вреда чем
пользы :) Я так скажу - в nginx такая
функциональность не нужна, а если так
нравятся alive чеки, никто не запрещает
вместо nginxа пользовать haproxy благо он http
тоже балансировать умеет (может уже и
кэшировать, давно в новые версии haproxy не
смотрел, хотя вряд ли :).



---
Igor

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?21,219032,220048#msg-220048

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru