mod_fcgid + php + nginx 0.7.64 = upstream prematurely closed connection while reading response header from upstream

[Одинцов Павел]

Добрый вечер!

Как я понял, proxy_pass как раз upstream неявно дергает.

Пробовали создавать односерверный апстрим:
upstream backend {
    server 88.198.x.x:8080 max_fails=300  fail_timeout=30s;
}

Но результат никакой - все равно огромное число потерь.

Также пробовали чит, который также не помог, но потерь стало
существенно меньше (а может и ошибаюсь):
upstream backend {
    server 88.198.x.x:8080 max_fails=300;
    server 88.198.x.x:8080 backup;
}

Ну в итоге почти так и решили, поставили дублирующий бэкэнд рядом:
upstream backend {
       server 88.198.x.x:8080;
       server 88.198.x.x:8081 backup;
}

Теперь число потерь 1-2 запроса из 1000. Так что все же это наиболее
правильное решение, ибо герйсфул апача с несколькими десятками fcgid
процессов - задачка мягко говоря, нетривиальная.


2010/1/26 Михаил Монашёв <postmaster at softsearch.ru>:
> Здравствуйте, Павел.
>
> ОП> Столкнулись с такой проблемой: nginx настроен на проксирование Apache,
> ОП> который выполняет PHP скрипты посредством mod_fcgid. При этом, у
> ОП> бэкэнда очень часто происходит "мягкий" реалоад апачи посредством
> ОП> /etc/init.d/apache reload. Проблема в том, что этот реалоад (как я
> ОП> понимаю, по вине mod_fcgid ) не совсем корректно, что приводит к куче
> ОП> 502х отбоев со следующей ошибкой в логах: upstream prematurely closed
> ОП> connection while reading response header from upstream
>
> ОП> При активированном дебаг логе выходит следующее:
> ОП> 2010/01/26 00:26:00 [debug] 689#0: *8 malloc: 0000000001F18FB0:4096
> ОП> 2010/01/26 00:26:00 [debug] 689#0: *8 recv: fd:21 0 of 4096 ### тут
> ОП> очень странно такое поведение
> ОП> 2010/01/26 00:26:00 [error] 689#0: *8 upstream prematurely closed
> ОП> connection while reading response header from upstream, client:
> ОП> 88.198.36.53, server: test1.ru, request: "GET / HTTP/1.0", upstream:
> ОП> "http://88.198.35.235:8080/", host: "test1.ru"
> ОП> 2010/01/26 00:26:00 [debug] 689#0: *8 http next upstream, 2
> ОП> 2010/01/26 00:26:00 [debug] 689#0: *8 free rr peer 1 4
> ОП> 2010/01/26 00:26:00 [debug] 689#0: *8 finalize http upstream request: 502
> ОП> 2010/01/26 00:26:00 [debug] 689#0: *8 finalize http proxy request
> ОП> 2010/01/26 00:26:00 [debug] 689#0: *8 free rr peer 0 0
> ОП> 2010/01/26 00:26:00 [debug] 689#0: *8 close http upstream connection: 21
> ОП> 2010/01/26 00:26:00 [debug] 689#0: *8 event timer del: 21: 1264454817346
> ОП> 2010/01/26 00:26:00 [debug] 689#0: *8 http finalize request: 502, "/?" 1
> ОП> 2010/01/26 00:26:00 [debug] 689#0: *8 http special response: 502, "/?"
> ОП> 2010/01/26 00:26:00 [debug] 689#0: *8 http set discard body
> ОП> 2010/01/26 00:26:00 [debug] 689#0: *8 HTTP/1.1 502 Bad Gateway
> ОП> Server: nginx/0.7.64
> ОП> Date: Mon, 25 Jan 2010 21:26:00 GMT
> ОП> Content-Type: text/html
> ОП> Content-Length: 173
> ОП> Connection: close
>
> ОП> Как я понял по исходникам, Апача принимает соединение, Nginx его также
> ОП> устанавливает успешно, но при чтении Nginx ом хидера, считывается нуль
> ОП> байт и на после этого клиент получает 502. Интересует возможность
> ОП> настройки Nginx (либо его пропатчивания) чтобы он делал вторую попытку
> ОП> коннекта, если первый раз получил пустой хидер.
>
> Используйте upsream вместо чёткого указания бэкенда.
>
> --
>
> С уважением,
> Михаил Монашёв, SoftSearch.ru
> mailto:postmaster at softsearch.ru
> ICQ# 166233339
> http://michael.mindmix.ru/
> Без бэкапа по жизни.
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://nginx.org/mailman/listinfo/nginx-ru
>



-- 
С уважением, Одинцов Павел