トラフィックの多いサイトで php-fpm を使用して nginx を実行しています。同じサーバー上で実行されているnginxとphp-fpmプールの両方で、nginxがtcp/ip経由でphp-fpmと通信できるようにしました。
tcp/ip を使用して nginx プールと php-fpm プールが相互に通信できるようにすると、ページの読み込みに数秒 (5 ～ 10 秒) かかってから何も実行されなくなり、最終的には時間がかかりません。ロードが完了するまですべて。php-fpm の statuspage を見るとリッスン バックログがいっぱいになっているので、リクエストが処理されるまでに時間がかかると思います。Netstat は、TIME_WAIT ステータスで多数 (20k+) の接続を示しています。これが関連しているかどうかはわかりませんが、関連しているように見えました。
nginx と php-fpm を UNIX ソケット経由で通信させようとすると、ページが実際に読み込まれるまでの時間がほとんどなくなり、完成したページがブラウザに表示されるまでの時間は 1000 分の 1 になります。UNIX ソケットの唯一の問題は、ログに多くのエラーが記録されることです。
*3377 connect() to unix:/dev/shm/.php-fpm1.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 122.173.178.150, server: nottherealserver.fake, request: "GET somerandomphpfile HTTP/1.1", upstream: "fastcgi://unix:/dev/shm/.php-fpm1.sock:", host: "nottherealserver.fake", referrer: "nottherealserver.fake"
私の2つの質問は次のとおりです。
tcp/ip メソッドが実際に php-fpm バックエンドに接続しているように見える前に、なぜそんなに大きな待ち時間があるのか、誰か知っていますか?
tcp/ip の代わりにこれを使用すると UNIX ソケットが問題を引き起こすのはなぜですか?
私が試したこと：
TIME_WAIT 接続の数を減らそうとするときに 1 に設定net.ipv4.tcp_tw_recycleしnet.ipv4.tcp_tw_reuseます (30k+ から 20k+ に減少しました)。
net.core.somaxconn値をデフォルトの 128 から 1024 に増やしました(これよりも高い値を試しましたが、UNIX ソケットを使用した場合でも同じエラーが発生しました)。
開いているファイルの最大数を増やしました
おそらく非常に関連性の高いもの: lighttpd + fastcgi を使用してみましたが、接続が最終的に処理されるまでに長い時間がかかるという同じ問題があります。MySQL はそれほどビジーではありません。長い待ち時間の原因ではありません。ディスク待機時間は 0% (SSD ディスク) であるため、ビジー状態のディスクも原因ではないようです。
誰かがこの問題の修正を見つけて、喜んで共有してくれることを願っています:)