ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: worker process exited on signal 11 (core dumped)



Hello!

On Wed, Feb 10, 2010 at 02:52:59PM +0300, Vladimir Sopot wrote:

> 
> On Feb 10, 2010, at 2:36 PM, Maxim Dounin wrote:
> 
> > Ok, кажется я понял проблему.  Судя по всему memcached_pass не 
> > дожидается полного прилёта trailer'а ("END") и ругается.  А в 
> > случае keepalive остатки trailer'а долетают в ответ на следующий 
> > запрос.
> > 
> > По идее строка "invalid trailer" должна наблюдаться и без 
> > keepalive (но скорее всего реже), а "invalid response" - только 
> > если keepalive включён.
> 
> 50 минут - полет нормальный, 
> 
> # grep -c 'subrequests cycle while processing' error.log
> 22076
> # grep memcached error.log
> #

Видимо "реже" в данном случае вырождается в "почти никогда".

> > Буду смотреть подробнее чуть позже.
> > 
> >> Заметил особенность некасательно этих ^^^ запросов. "subrequests 
> >> cycle while processing" возникают очень часто на #51 ssi include 
> >> virtual. Фактически увидел НЕ на #51 всего несколько раз из 
> >> сотни.
> > 
> > Потому что проверка на циклы срабатывает когда одновременно 
> > обрабатывается более 50 подзапросов.
> 
> Тоесть на странице не должно быть более 50 поздзапросов? Это неизменяемо?

Если больше - надо бить на куски, вставляя в промежутках 
include ... wait="yes".

Just in case it's not clear: без защиты всё превращается в тыкву 
если случается более 255 подзапросов одновременно, ибо 
переполняется счётчик ссылок на основной запрос.

> >>>>>> location ~ /mmc/today/(\d+) {
> >>>>>>        internal;
> >>>> 
> >>>> Кстати, даже с internal ЭТО доступно из броузера.. Как же так?
> >>> 
> >>> С internal происходит 404, а он у вас перехвачен в то же самое но 
> >>> на php.
> >>> 
> >>>>>>        set $memcached_key "today_$1";
> >>>>>>        memcached_pass tablew_mmc;
> >>>>>>        error_page 404 502 /main/ssi/today_counter.php?ad=$1;
> >>>>>>        }
> >> 
> >> - error_page 404 502 /main/ssi/today_counter.php?ad=$1;
> >> + error_page 404 502 = /main/ssi/today_counter.php?ad=$1;
> >> 
> >> location ^~ /main/ {
> >>    include fastcgi_params;
> >>    }
> >> 
> >> location /main/ssi/ {
> >>    internal;
> >>    include fastcgi_params;
> >>    }
> >> 
> >> при запросе /main/ssi/today_counter.php имеем 404, при /mmc/today - 
> >> нормальный ответ.
> >> Чую западню, но не понимаю где :(
> > 
> > Попадание внешнего запроса в location с флагом internal приводит к 
> > возврату 404 ошибки.  Случается внутренний редирект на страницу 
> > ошибки.  И возврат этой страницы, даже если она тоже в location 
> > с флагом internal - т.к. запрос 404 ошибки уже внутренний.
> 
> Перефразирую, можно ли добиться недоступности /mmc/today в моем случае?

Только как-то так:

location /internal/ {
    internal;
    error_page 405 = @memcached;
    return 405;
}

location @memcached {
    memcached_pass ...
    error_page 404 502 = @fastcgi;
}

location @fastcgi {
    fastcgi_pass ...
}

Т.е. в location с флагом internal не должно быть обработчика 404 
ошибки, ведущего куда не надо.

Maxim Dounin

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


 




Copyright © Lexa Software, 1996-2009.