39

JSON 応答を返す REST API があります。ときどき (完全にランダムなように見えますが)、json の応答が途中で途切れることがあります。したがって、返される json 文字列は次のようになります。

...route_short_name":"135","route_long_name":"Secte // end of response

返されるjson文字列に応じて、カットオフポイントの位置が変化し続けるため、エンコードの問題ではないと確信しています。カットオフが発生する特定の応答サイズも見つかりませんでした（65kbはカットオフされませんが、40kbsはカットオフされます）。

切断が発生したときの応答ヘッダーを見ると、次のようになります。

{
    "Cache-Control" = "must-revalidate, private, max-age=0";
    Connection = "keep-alive";
    "Content-Type" = "application/json; charset=utf-8";
    Date = "Fri, 11 May 2012 19:58:36 GMT";
    Etag = "\"f36e55529c131f9c043b01e965e5f291\"";
    Server = "nginx/1.0.14";
    "Transfer-Encoding" = Identity;
    "X-Rack-Cache" = miss;
    "X-Runtime" = "0.739158";
    "X-UA-Compatible" = "IE=Edge,chrome=1";
}

ベルも鳴らさない。誰？

4

7 に答える 7

37

私は同じ問題を抱えていました：

Nginx は、FastCGI バックエンドからのいくつかの応答を遮断しました。たとえば、PhpMyAdmin から適切な SQL バックアップを生成できませんでした。ログを確認したところ、次のことがわかりました。

2012/10/15 02:28:14 [crit] 16443#0: *14534527 open() "/usr/local/nginx/fastcgi_temp/4/81/0000004814" が失敗しました (13: 許可が拒否されました) アップストリームの読み取り中に、クライアント: *、サーバー:、リクエスト: 「POST /HTTP/1.1"、アップストリーム: "fastcgi://127.0.0.1:9000"、ホスト: ""、リファラー: "http://*/server_export.php?token=** "

それを修正するために私がしなければならなかったのは、/usr/local/nginx/fastcgi_tempフォルダーとclient_body_temp.

修理済み！

どうもありがとうsamvermette、あなたの質問と回答は私を正しい軌道に乗せました。

于 2012-10-15T00:43:56.500 に答える
31

私のnginxerror.logファイルを調べたところ、次のことがわかりました。

13870 open() "/var/lib/nginx/tmp/proxy/9/00/0000000009" failed (13: Permission denied) while reading upstream...

nginx のプロキシが (thin によって渡された) 応答コンテンツをファイルに保存しようとしていたようです。これは、応答サイズがproxy_buffers(64 ビット プラットフォームではデフォルトで 64kb) を超えた場合にのみ行われます。結局、バグは私のリクエスト応答サイズに関連していました。

ファイルのアクセス許可の問題をアップまたは修正するのではなく、nginx 構成ファイルで に設定proxy_bufferingすることで、問題の修正を終了しました。offproxy_buffers

nginxのバッファの目的についてはまだわかりません。誰かがそれについて追加できれば幸いです。バッファリングを完全に無効にするのは悪い考えですか?

于 2012-05-11T21:09:59.943 に答える
2

NginX が fastcgi_temp ディレクトリを適切に使用できなくなる inode が不足している可能性があります。

試してみてdf -i、空いている inode が 0% の場合、それは問題です。

(10 日以上前) を試してfind /tmp -mtime 10、何がディスクをいっぱいにしているかを確認してください。

または、ファイルが多すぎる別のディレクトリである可能性があります。たとえば、/home/www-data/example.com に移動して、ファイルを数えます。

find . -print | wc -l

于 2014-02-05T09:37:46.427 に答える
2

質問と素晴らしい回答をありがとう、それは私に多くの時間を節約しました. 最後に、クレメントとサムの答えが私の問題を解決するのに役立ったので、クレジットは彼らに送られます。

トピックについて少し読んだ後、proxy_bufferingたとえばクライアント（システムのユーザー）のインターネット接続が悪い場合にサーバーが停止する可能性があるため、無効にすることはお勧めできません.

このディスカッションは、理解を深めるのに非常に役立ちました。フランシス・デイリーの例は、私にとってそれを非常に明確にしました：

おそらく、プロセス全体を一連のプロセスと考える方が簡単でしょう。

Web ブラウザーは、1 MB/秒のリンクを介して nginx と通信します。nginx は、100 MB/秒のリンクを介してアップストリーム サーバーと通信します。アップストリーム サーバーは 100 MB のコンテンツを nginx に返します。nginx は 100 MB のコンテンツを Web ブラウザーに返します。

proxy_buffering をオンにすると、nginx は 100 MB 全体を保持できるため、nginx とアップストリームの接続は 1 秒後に閉じることができ、その後、nginx はコンテンツを Web ブラウザーに送信するのに 100 秒費やすことができます。

proxy_buffering をオフにすると、nginx は、nginx が Web ブラウザーに送信できるのと同じ速度で、上流からコンテンツを取得することしかできません。

Web ブラウザーは違いを気にしません。コンテンツ全体を取得するのに 100 秒かかります。

nginx は違いをあまり気にしません。ブラウザにコンテンツをフィードするのに 100 秒かかりますが、アップストリームへの接続を 99 秒間開いたままにしておく必要があります。

アップストリームは違いを気にします-1秒かかる可能性があるものは、実際には100秒かかります。余分な 99 秒間、そのアップストリーム サーバーは他の要求を処理していません。

通常: nginx-upstream リンクは browser-nginx リンクより高速です。アップストリームはnginxよりも「重い」です。そのため、アップストリームにできるだけ早く処理を終了させることが賢明です。

于 2016-01-27T13:53:26.247 に答える