私はPumaをアップストリームアプリケーションサーバーとして、そしてRiakを私のバックグラウンドデータベースクラスターとして実行しています。約25Kユーザーのデータの塊をmap-reductionしてRiakからアプリに返すというリクエストを送信すると、Nginxログにエラーが発生します。
アップストリームからの応答ヘッダーの読み取り中にアップストリームがタイムアウトしました(110:接続がタイムアウトしました)
同じリクエストで、nginxプロキシなしで直接アップストリームに問い合わせると、必要なデータが得られます。
Nginxタイムアウトはプロキシが入れられると発生します。
**nginx.conf**
http {
keepalive_timeout 10m;
proxy_connect_timeout 600s;
proxy_send_timeout 600s;
proxy_read_timeout 600s;
fastcgi_send_timeout 600s;
fastcgi_read_timeout 600s;
include /etc/nginx/sites-enabled/*.conf;
}
**virtual Host conf**
upstream ss_api {
server 127.0.0.1:3000 max_fails=0 fail_timeout=600;
}
server {
listen 81;
server_name xxxxx.com; # change to match your URL
location / {
# match the name of upstream directive which is defined above
proxy_pass http://ss_api;
proxy_set_header Host $http_Host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_cache cloud;
proxy_cache_valid 200 302 60m;
proxy_cache_valid 404 1m;
proxy_cache_bypass $http_authorization;
proxy_cache_bypass http://ss_api/account/;
add_header X-Cache-Status $upstream_cache_status;
}
}
Nginxにはたくさんのタイムアウトディレクティブがあります。重要なものが足りないかどうかはわかりません。任意の助けは非常に高く評価されるでしょう....
あなたは常にタイムアウトの増加を控えるべきです、私はあなたのバックエンドサーバーの応答時間がどんな場合でもここの問題であるとは思わない。
この問題を回避するには、接続キープアライブフラグをクリアし、回答に従ってhttpバージョンを指定します。 https://stackoverflow.com/a/36589120/479632
server {
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_Host;
# these two lines here
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass http://localhost:5000;
}
}
残念ながら、なぜこれが機能するのか説明することはできず、リンクされている回答に記載されている文書からそれを解読することもできませんでした。
これは、あなたのアップストリームがリクエストに答えるのにあまりにも多くの時間がかかり、NGINXがアップストリームがすでにリクエストの処理に失敗したと考え、エラーで応答するために起こります。単にlocationにproxy_read_timeoutを含めて増やすだけです。同じことが私にも起こりました、そして私は仕事で内部のアプリのために1時間のタイムアウトを使いました:
proxy_read_timeout 3600;
これにより、NGINXはアップストリームが何かを返すのを1時間待ちます。
最初にnginxエラーログファイルを調べてどのアップストリームが遅くなっているかを把握し、それに応じて読み込みタイムアウトを調整します(私の場合はfastCGIです)。
2017/09/27 13:34:03 [error] 16559#16559: *14381 upstream timed out (110: Connection timed out) while reading response header from upstream, client:xxxxxxxxxxxxxxxxxxxxxxxxx", upstream: "fastcgi://unix:/var/run/php/php5.6-fpm.sock", Host: "xxxxxxxxxxxxxxx", referrer: "xxxxxxxxxxxxxxxxxxxx"
だから私は私のサーバーの設定でfastcgi_read_timeoutを調整する必要があります
location ~ \.php$ {
fastcgi_read_timeout 240;
...
}
参照してください: 元の記事
このエラーはさまざまな理由で発生する可能性があると思いますが、使用しているモジュールに固有のものである可能性があります。例えば、私はこれをuwsgiモジュールを使って見たので、 "uwsgi_read_timeout"を設定しなければなりませんでした。
あなたの場合、それはプロキシーでの少しの最適化を助けます、またはあなたは「#タイムアウト設定」を使うことができます
location /
{
# time out settings
proxy_connect_timeout 159s;
proxy_send_timeout 600;
proxy_read_timeout 600;
proxy_buffer_size 64k;
proxy_buffers 16 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_pass_header Set-Cookie;
proxy_redirect off;
proxy_hide_header Vary;
proxy_set_header Accept-Encoding '';
proxy_ignore_headers Cache-Control Expires;
proxy_set_header Referer $http_referer;
proxy_set_header Host $Host;
proxy_set_header Cookie $http_cookie;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $Host;
proxy_set_header X-Forwarded-Server $Host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Error_logs、特にタイムアウトが発生している特定のアップストリームを示すアップストリーム部分を確認することをお勧めします。
それに基づいて、proxy_read_timeout、fastcgi_read_timeout、またはuwsgi_read_timeoutを調整できます。
設定がロードされていることも確認してください。
他の多くの人がここで指摘しているように、NGINXのタイムアウト設定を増やすことはあなたの問題を解決することができます。
ただし、タイムアウト設定を増やすことは、これらの回答の多くが示すほど簡単ではないかもしれません。私は自分自身がこの問題に直面しており、/ etc/nginx/nginx.confファイルのタイムアウト設定を変更しようとしました。これは私を少し助けていませんでした。 NGINXのタイムアウト設定に明らかな変更はありません。何時間も経った今、ようやくこの問題を解決することができました。
解決策は このフォーラムのスレッド にあります、そしてそれが言うことはあなたがあなたのタイムアウト設定を/ etc/nginx/confに置くべきであるということです.d/timeout.conf(このファイルが存在しない場合は、作成する必要があります)。私はスレッドで提案されているのと同じ設定を使用しました:
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
私たちの側からは、プロキシキャッシュ付きのspdyを使用していました。キャッシュが期限切れになると、キャッシュが更新されるまでこのエラーが発生します。
うまくいけばそれは誰かに役立ちます:私はこのエラーに遭遇し、原因はphpfpmがそれに書き込めるようにそれを変更した後、ログフォルダの間違った許可があった、すべてが大丈夫でした。
私は同じ問題を抱えていました、そしてそれはRailsコントローラの「毎日の」エラーでした。理由はわかりませんが、本番環境では、pumaが何度も何度もエラーを実行してメッセージを表示します。
アップストリームからのレスポンスヘッダの読み取り中にアップストリームがタイムアウトしました(110:接続がタイムアウトしました)
おそらくNginxがpumaから何度も何度もデータを取得しようとしているからです。おもしろいことに、コントローラで別のアクションを呼び出してもエラーによってタイムアウトメッセージが表示されます。
それが状況であるかどうか見るためにあなたのlog/puma.stderr.logファイルをチェックしなさい。