スタック: nginx、uwsgi、django
uwsgitop と top はどちらも uwsgi ワーカーがアイドル状態であることを示していましたが、nginx エラー ログにはアップストリームのタイムアウトが示されていました。
リクエストの中には、db やキャッシュの待機など、多くのリソースが必要なものもあれば、そうでないものもあると思いました。タイムアウトしたリクエストを確認したところ、それらのほとんどは貪欲ではありませんでした。あらゆる種類の要求がタイムアウトになりました。
では、他のリクエストが本当に忙しいのに、なぜ nginx はリクエストをアイドル状態のリクエストにシードしなかったのでしょうか? なぜuwsgiマスターは誰かを忙しくさせ、他の人はアイドル状態にするのですか?
私自身の質問に答えたいと思います。
カーネル パラメータを変更します: net.ipv4.ip_conntrack_max を 65560 から 6556000 に変更します。
私たちがどのように答えを見つけたかについての完全な話があります：
ユーザーは遅い、遅い、遅いと言った
nginx が「upstream connection timed out」であふれました
uwsgi のログを確認したところ、いくつかのエラーが見つかり、修正されました。さらに見つけ、さらに修正し、このループは何日も続きました。昨日まで、uwsgi がアイドル状態だったので、uwsgi、memcached、db、redis、またはその他のバックエンドとの関連性はないと思っていました
だから私はnginxに何か問題があったに違いないと思った、リロード、再起動、接続のチェック、ワーカー、proxy_read_timeoutなど。
ulimit -n をチェックすると、デフォルトの 1024 が報告されました。私は 8 つの nginx ワーカーを持っているので、接続は 1024 * 8 に達するはずです。nginx は開いているファイルが多すぎるとは言わなかったので、問題ないと思いました。とにかく、私はそれを 4096 に変更しました。
接続数と状態を確認すると、問題が発生します。アップストリーム接続はすべて syn_sent 状態で、その後タイムアウトが発生しました。300 の接続のうち、確立された状態にあるのは 2 つまたは 3 つだけです。その理由を知りたかったのです。私の友人の 1 人が、tcpdump を使用するように私に言いました。
次にsyslogに行き、次のエラーを見つけ、最終的に問題を解決しました