Игорь, не могли бы вы объяснить, в каких случаях выдаются следующие
ошибки для 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.
Игорь Сысоев
