FastCGI errors: upstream timed out, connection reset by peer

[Igor Sysoev]

On Sat, 22 Apr 2006, Mike Kolesnikov wrote:

> Игорь, не могли бы вы объяснить, в каких случаях выдаются следующие
> ошибки для FastCGI:
>
> 2006/04/21 16:26:57 [error] 10354#0: *4890399 upstream timed out (110:
> Connection timed out) while sending request to upstream...
>
> 2006/04/21 13:57:53 [error] 10356#0: *4609378 recv() failed (104:
> Connection reset by peer) while reading response header from upstream...
>
> Я подозреваю, что вторая случается, если FastCGI сервер (в данном случае
> PHP) падает или другим образом некорректно завершает соединение.
>
> Но почему происходит первая, неясно - вначале я думал, что это из-за
> превышения fastcgi_connect_timeout или fastcgi_send_timeout, запустил 5
> процессов PHP, залочил все 5 с помошью mysql, так что новые запросы к
> PHP "зависали", но они так до сих пор и висят вот уже 2 часа.
> И это при вот таких значениях:
>                fastcgi_connect_timeout       10;
>                fastcgi_send_timeout          2m;
>                fastcgi_read_timeout          12h;
> Неужто из-за большого fastcgi_read_timeout? Т.е. connect проходит,
> несмотря на то, что процессы все заняты? А как же send_timeout? Если
> даже так, это опять же не объясняет причину ошибки "upstream timed out"
> в логах, при таком read_timeout ее быть вообще не должно.

Сейчас при таймауте при сonnect() nginx выдаёт сообщение про
"sending request to upstream". В 0.3.42 это будет исправлено.
Что касается успешного connect() при занятых бэкендах, то это возможно:
соединения ставяться в очередь в listen queue.

Что касается второго сообщения, то, скорее всего, дело в TIME_WAIT.
Судя по номерам ошибок, это Линукс. Если бэкенд тоже на Линуксе, то что
показывает на нём

cat /proc/sys/net/ipv4/tcp_tw_recycle

? Если 0, то нужно поставить 1.


Игорь Сысоев
http://sysoev.ru