Re: миграция с 0.5.32 на 0.6.31

[Alexey V. Karagodov]

On 19.06.2008, at 17:35, jackal wrote:

> On Thursday 19 June 2008 16:57:28 Igor Sysoev wrote:
>> On Thu, Jun 19, 2008 at 03:45:13PM +0400, jackal wrote:
>>> Обновился до 0.6.31, и появилось несколько вопросов:
>>>
>>> 1) Нужно, чтобы домен domain.ru был в одной директиве server, а все
>>> остальные - в другой.
>>>
>>> Раньше было:
>>> server {
>>>  listen       a.b.c.d:80 default accept_filter=httpready  
>>> backlog=4096;
>>>  listen       80 default accept_filter=httpready backlog=4096;
>>>  server_name  srv *;
>>>  ...
>>> }
>>> server {
>>>  listen      a.b.c.d:80;
>>>  server_name  domain.ru;
>>>  ...
>>> }
>>>
>>> Сейчас, ввиду упразднения "server_name *", стало:
>>> server {
>>>  listen       a.b.c.d:80;
>>>  server_name  domain.ru;
>>>  ...
>>> }
>>> server {
>>>  listen       a.b.c.d:80 default accept_filter=httpready  
>>> backlog=4096;
>>>  listen       80 default accept_filter=httpready backlog=4096;
>>>  ...
>>> }
>>>
>>> Т.е. сервера поменялись местами. Всё работает, но:
>>> а) ругается при старте:
>>> [warn] 13775#0: conflicting server name "domain.ru" on a.b.c.d:80,
>>> ignored
>>
>> По-видимому, hostname - domain.ru, нужно описать какое-нибудь имя во
>> втором сервере.
>
> Угу, так и есть. А как описать какое-нибудь имя во втором сервере,
> если "звездочка" запрещена?
> Или роль звездочки будет выполнять listen ... default?
>
> http://sysoev.ru/nginx/docs/http/ngx_http_core_module.html#listen
> Ага, вроде так и есть...

"звёздочку" можно описать регекспом ^(.*)$
как вариант
но в данное описание server_name *не* попадут IP адреса, т.е. запрос http://127.0.0.1/ 
  уйдёт на 'default'
IP надо будет описывать(перечислять) явно
либо делать как в доках

>
>
>
>>
>>> б) На айпи a.b.c.d похоже не работает httpready
>>
>> Из чего сделан такой вывод ?
>
> Во втором сервере:
> listen       a.b.c.d:80 default accept_filter=httpready backlog=4096;
> listen       80 default accept_filter=httpready backlog=4096;
>
> Если изменить backlog на 1024, получается вот такая картина:
> tcp4  0/0/4096       a.b.c.d.80
> tcp4  0/0/1024       *.80
> (kern.ipc.somaxconn=4096)
>
> Т.е. видно, что backlog для a.b.c.d не работает. Отсюда сделан  
> вывод, что
> accept_filter - тоже. Т.к. в мануале написано, что backlog и  
> accept_filter
> можно указывать только совместно с директивой default
>
>
>>
>>> 2) nginx проксирует апач. Апач "форкнут" на 12 процессов (ни  
>>> больше ни
>>> меньше). Раньше при кратковременных пиковых нагрузках апач
>>> "аккумулировал" коннекты в очереди, а nginx покорно ждал. Сейчас  
>>> же -
>>> nginx сразу же отдает bad gateway.
>>> Настройки идентичны:
>>>    proxy_connect_timeout      10;
>>>    proxy_send_timeout         30;
>>>    proxy_read_timeout         30;
>>>    proxy_send_lowat           12000;
>>>    proxy_buffer_size          8k;
>>>    proxy_buffers              32 32k;
>>> Имеется ввиду примерно следующая ситуация:
>>> Current listen queue sizes (qlen/incqlen/maxqlen)
>>> Proto Listen         Local Address
>>> tcp4  181/0/511      127.0.0.1.8080
>>> tcp4  0/0/4096       a.b.c.d.80
>>> tcp4  0/24/4096      *.80
>>> Т.е. очередь апача не переполнена, т.ч. коннекты не дропаются.
>>> Как такое лечить? :) М.б. это связано с проблемой 1б?
>>
>> А в error_log какая ошибка ?
>
> Здесь прошу прощения, ступил. nginx честно ждет отведенные 30  
> секунд, и выдает
> bad gateway с ошибкой upstream timed out. Проблема была в бэкенде.
>