nginxエラー「recv（）が失敗しました（104：ピアによって接続がリセットされました）が、アップストリームから応答ヘッダーを読み取り中です」

2013年10月3日午前10時50分に断続的に「502 Bad Gateway」エラーをクライアントに返し始めたサーバーは正常に動作していました。

5つのブラウザリクエストのうち約4つが成功しますが、5つのうち約1つが502で失敗します。

nginxエラーログには、これらのエラーが何百も含まれています。

2013/10/05 06:28:17 [error] 3111#0: *54528 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 66.249.66.75, server: www.bec-components.co.uk  request: ""GET /?_n=Fridgefreezer/Hotpoint/8591P;_i=x8078 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.bec-components.co.uk"

ただし、PHPエラーログには一致するエラーは含まれません。

接続をリセットしている理由について、PHPに詳細情報を提供する方法はありますか？

これはnginx.conf;

user              www-data;
worker_processes  4;
error_log         /var/log/nginx/error.log;
pid               /var/run/nginx.pid;

events {
   worker_connections  1024;
}

http {
  include          /etc/nginx/mime.types;
  access_log       /var/log/nginx/access.log;

  sendfile               on;
  keepalive_timeout      30;
  tcp_nodelay            on;
  client_max_body_size   100m;

  gzip         on;
  gzip_types   text/plain application/xml text/javascript application/x-javascript text/css;
  gzip_disable "MSIE [1-6]\.(?!.*SV1)";

  include /gvol/sites/*/nginx.conf;

}

これが.confこのサイト用です。

server {

  server_name   www.bec-components.co.uk bec3.uk.to bec4.uk.to bec.home;
  root          /gvol/sites/bec/www/;
  index         index.php index.html;

  location ~ \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires        2592000;   # 30 days
    log_not_found  off;
  }

  ## Trigger client to download instead of display '.xml' files.
  location ~ \.xml$ {
    add_header Content-disposition "attachment; filename=$1";
  }

   location ~ \.php$ {
      fastcgi_read_timeout  3600;
      include               /etc/nginx/fastcgi_params;
      keepalive_timeout     0;
      fastcgi_param         SCRIPT_FILENAME  $document_root$fastcgi_script_name;
      fastcgi_pass          127.0.0.1:9000;
      fastcgi_index         index.php;
   }
}

## bec-components.co.uk ##
server {
   server_name   bec-components.co.uk;
   rewrite       ^/(.*) http://www.bec-components.co.uk$1 permanent;
}

私のウェブサーバーが私に言っているなら、私は常に信頼しています： 502 Bad Gateway

• fastcgi / nginxプロセスの稼働時間はどのくらいですか？
• ネットワーク接続を監視していますか？
• その日の訪問者数の変更を確認/拒否できますか？

どういう意味ですか：

• fastcgi-processはnginxからアクセスできません。遅くなるか、まったく対応しません。不良ゲートウェイとは、nginxが定義されたressource 127.0.0.1:9000にfastcgi_passできないことを意味します。その非常に特定の瞬間に。

• あなたの初期エラーログはそれをすべて伝えます：

。

recv() failed 
    -> nginx failed

(104: Connection reset by peer) while reading response header from upstream, 
    -> no complete answer, or no answer at all
upstream: "fastcgi://127.0.0.1:9000", 
    -> who is he, who failed???

私の限られたPOVから私はお勧めします：

• fastcgi_process /サーバーを再起動します
• アクセスログを確認してください
• デバッグログを有効にする

私はこのトピックが古いことを知っていますが、それでも時々時々ポップアップするので、ウェブで答えを探して、私は次の3つの可能性を思いつきました：

1. プログラミングエラーがphp-fpmをセグメンテーション違反にすることがあります。これは、nginxとの接続が切断されることを意味します。これにより、通常、少なくともいくつかのログやコアダンプが残り、さらに分析できます。
2. 何らかの理由で、PHPはセッションファイルを書き込むことができません（通常：）session.save_path = "/var/lib/php/sessions"。これは、アクセス許可、所有権、ユーザー/グループ、またはそのディレクトリ（またはディスク全体）でiノードが不足するなどの難解な/あいまいな問題です。これは通常、多くのコアダンプを残さず、PHPエラーログにも何も残しません。
3. デバッグがさらに難しい：拡張機能の誤動作（ある種の内部制限、または常にトリガーされないバグ）、セグメンテーション違反、php-fpmプロセスの停止-nginxとの接続を閉じる。通常の犯人はAPC、memcache / dなど（私の場合はNew Relic拡張機能）であるため、ここでの考え方は、エラーが消えるまで各拡張機能をオフにすることです。

これも取得し続けました。opcache使用する場合は、メモリ制限を増やして解決しました（APCの置き換え）。キャッシュがいっぱいになったときにPHP-FPMが接続をドロップしたようです。これはまた、shgnIncの答えが短時間それを修正する理由でもあります。

そのため、ファイル/etc/php5/fpm/php.ini（またはディストリビューションで同等のもの）を見つけてmemory_consumption、サイトが必要とするレベルまで増やします。無効化opcacheも機能する場合があります。

[opcache]
opcache.memory_consumption = 196 

githubでこのgitを検討してください：https : //gist.github.com/amichaelgrant/90d99d7d5d48bf8f​​d209

同様の状況が発生しました。アップストリームサーバーのエラーログをチェックすると、ulimitエラーが報告されていたため、1000000（アップストリームとnginxの両方のボックスで）に増やしました。

同じ問題が発生した場合、php-fpmサービスを再起動するだけで解決しました。

sudo service php5-fpm restart

または、大量のリクエストが原因でこの問題が発生する場合があります。デフォルトではpm.max_requests、php5-fpmの値は100以下です。

それを解決するには、サイトのリクエストに応じて値を増やします（例：500）。

そして、あなたがサービスを再起動する必要がある後

私の場合、xdebug拡張機能を無効にすると役に立ちました。

私は同様の問題がありました：

ポート9000でphp-fpmに接続します（fastcgi：//127.0.0.1：9000）

サーバー上のUbuntuの標準構成は次のとおりです。

/etc/php/7.0/fpm/pool.d/www.conf：

listen = /run/php/php7.0-fpm.sock

これを次のように変更する必要があります。

listen = 0.0.0.0:9000

私の場合、1か月前にサーバーを更新し、デフォルトでcostom構成を上書きしました。php-fpmを再起動すると、このエラーは遅れて発生しました。

私にとっては、サーバーがメモリ不足で、php-fpmがOOMキラーに殺されていました。解決策は、サーバーのメモリ量を増やすことでした。

私にとっては、php-fpmがmax_children限界に達していたからです。問題のプールのphp-fpmログは正しい方向を示してくれました

この問題は、PHP-FPMプロセスが割り当てられたメモリ制限を超えた場合にも発生する可能性があります。これが発生すると、NGINXとPHP-FPM間の接続が切断され、NGINXはを返します502 Bad Gateway。PHP-FPMプロセスのメモリ制限は、memory_limit変数によって制御されます。これはphp_admin_value[memory_limit]、PHP-FPM構成ファイルで設定できます。

メモリ制限はスクリプトごとに適用されることに注意することが重要です。nPHP-FPMプロセス、総メモリ使用量が最大になることができますmemory_limit * n。マシンに十分なメモリヘッドルームがあることを確認してください！