Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[3]: PHP FastCGI и "upstream prematurely closed connection"
Hello Сухачев,
Monday, April 9, 2007, 3:08:59 PM, you wrote:
> Hello Roxis,
> Monday, April 9, 2007, 11:45:44 AM, you wrote:
>> On Monday 09 April 2007, Сухачев Андрей wrote:
>>> By default, PHP stops accepting new FastCGI connections after handling
>>> 500 requests; unfortunately, there is a potential race condition during the
>>> PHP cleanup code in which PHP can be shutting down but still have the
>>> socket open, so mod_fcgid under heavy load can send request number 501 to
>>> PHP and have it "accepted", but then PHP appears to simply exit, causing
>>> errors.
>>> Надо будет проверить это...
>> PHP_FCGI_MAX_REQUESTS по дефолту равно 500
> Да, именно на это и подозрения. В самом коде php-cgi написано:
> int max_requests = 500;
> ...
+ char *php_max_requests = getenv("PHP_FCGI_MAX_REQUESTS");
- if (getenv("PHP_FCGI_MAX_REQUESTS"))
+ if (php_max_requests)
- max_requests = atoi(getenv("PHP_FCGI_MAX_REQUESTS"));
+ max_requests = atoi(php_max_requests);
> ...
> requests++;
> if (max_requests && (requests == max_requests)) {
> FCGX_Finish_r(&request);
> /* end of fastcgi loop */
> }
:)
> И я очень сильно подозреваю, что запросы, которые попадают в этот интервал
> и падают в лог с
> " upstream prematurely closed connection while reading response header from
> upstream".
> Интересно, а nginx может в случае отлупа от fast-cgi сервера,
> посылать запрос на следующий fast-cgi?
> Тогда можно было бы в тупую обойти это:
> upstream {
> server fastcgi://127.0.0.1:9000;
> server fastcgi://127.0.0.1:9000;
> }
> Тогда даже если запрос попадает на такой "умирающий" процесс, nginx его
> просто перебросит на
> другой процесс. Шансы что тот тоже окажется умирающим близки к нулю.
--
Best regards,
Denis Latypoff mailto:latypoff@xxxxxxxxx
|