phpとmysqlでsleepの空接続処理を減らす方法

開発したシステムでは、データベースのスリープ状態に多数の空の接続が存在すると同時に、サードパーティ API のフィードバックに多数の例外があることがログからわかります。システム内のphpのcurlを通じてリクエストされたインターフェイス。その理由を分析するには、この2つを接続せずにはいられません。ログには、サードパーティのインターフェイスの応答が遅く、結果が空であることが示されています。理由は不明ですが、待機プロセス中に PHP が接続が戻るのを待っていると考えられます。プロセスの実行後にカールがタイムアウトし、データベース リンクが解放されるまでスリープします。

1. PHP+mysql+memcache 実践技術テスト

問題は非常に異常ですが、すべて実戦で遭遇した実際のケースです

1: 両方を必要とするプログラムを作成します。 mysqlを使用するときは、memcacheも使用する必要があります。

最初の行は

mysql_connect、2行目はmemcache_connect

上書きします、1行目はmemcache_connect、2行目はmysql_connect

caozはこれら2つの方法を見つけました実際に書くと大きな違いがありますが、何が違うのでしょうか？

2: mysql を使用してプログラムを作成し、ページを生成し、最後に echo $html; を使用して出力しました

1 つの書き方は

mysql_close();

echo $html;

もう 1 つの方法です。

echo $html;

mysql_close();

caoz は、実際には 2 つの間に大きな違いがあることに気付きました。その違いは何ですか?

どちらも実際に発見され、調整されたケースです。

caoz は、プログラムを書くときに BT を追求する人ではありません。caoz はエンジニアに対して、極端な技術的表現や技術的な誇示を追求するものではないことをよく強調します。この書き方は、特定の書き方よりもリソースの消費が少ないです。 ちょっとしたことやその他のことであれば、これは実際には caoz の意図ではありません。

これら 2 つの質問は、実際の運用環境で遭遇する典型的なケースです。典型的なケースはどこですか?つまり、システム障害が発生したときに、関連する複数の要因の影響をどのように分析し、どのように考え、どのように判断するかということが重要です。したがって、この質問に答えられるかどうかは重要ではありません。システム間の関係をどのように考えるかです。

典型的なシステム障害は、mysql 接続が多すぎること、または接続が多すぎることです。この問題がインデックス作成や同時データ要求によって引き起こされている場合、原因を特定するのはそれほど難しくありません。上記の問題は解決され、奇妙な現象は発生しませんでした。データベースへの負荷はほとんどなく、プロセスのブロックも、クエリの遅延も発生しませんでした。ただし、mysql 接続はすべてスリープ接続でした。このとき、Web サーバーへのリンクも多数存在します。つまり、PHP の実行がブロックされているため、MySQL のリンクがすぐに解放されないのです。では、なぜ PHP がブロックされるのでしょうか。 ブレークポイントごとの分析により、エコーの遅延が最も長かったことが判明しました。

このインシデントは caoz にいくつかの経験を与えました。私はこれまでエコーが時間のブロックポイントであるとは考えたこともありませんでしたが (このマシンでテストすると、その時間遅延はほぼ 0 であると思われるでしょう)、インスタンスの追跡により、実際にはエコーが時間ブロックポイントであることがわかりました。私たちの作業環境では、代表的なネットワーク送信プロセスは、ルーティングと帯域幅の要因により待機します。この時点では、mysql リンクはまだ存在しており、解放されていません。はい、誰もが mysql_close を思い浮かべるでしょう。タイトルを参照してください。これはエコーの後に配置する必要がありますが、なぜエコーが時間を遅らせるのかを考える人はほとんどいないでしょう。もちろん、これは動作環境にも関係します。Caoz は、設定した Web サーバーでこの状況が発生することを知っているだけです。Caoz はそれをテストしていないので、ここでの経験は次のとおりです。 mysql_close が echo の前に配置されると、多数のスリープ リンクが急速に減少します。

echo はシステム リソースをあまり消費しませんが、同時実行性の高いネットワーク環境では、データベースがこれに注意することをお勧めします。

この問題が解決されてから、mysql はより健全になりましたが、リンクが多すぎるという問題が時折発生し、長い間私を悩ませていました。ある日、ユーザーから報告されたいくつかの

エラー メッセージ に基づいて、 memcached サーバーが不安定だったことが判明しました。memcached のトラフィックが多すぎてブロックされ、PHP プロセスがリンクを待機しているため、多数の mysql リンクが待機していることがわかりました。これが最初の質問の原因です。この質問自体に対する標準的な答えはありませんが、スクリプト内で 2 つのリンク A と B を同時に開始することを認識しておく必要があります。これら 2 つのリンクが必ずしも信頼できるかどうかを保証できない場合 (通常は保証できません)、後者がブロックされると、前者は多数のリンクを待機することになりますが、前者はブロックされ、通常は後者に影響を与えません。したがって、答えは、アプリケーションにとってどのリンクがより重要であるか、またどのリンクがより優れた同時実行サポートを備えているかによって異なります。

最終的には、どちらの質問も同じことを意味します。システムの問題や障害が発生した場合は、いくつかの関連要因の影響と、アーキテクチャ全体の応答シーケンスのロジックについてよく考えてください。データベース接続が多すぎることが必ずしも原因であるとは限りません。はい、Web リンクが多すぎるため、Web サーバーを最適化する必要はありません。根本原因を解決することによってのみ、症状が完全に解決されます。

2. MySQL のスリーププロセスを削減する効果的な方法

1. 一般的に、MySQL は PHP の MySQL ロングリンクデータベースメソッドを採用しているため、つまり、mysql_pconnect を使用してリンクされたデータベースを開くため、多数のスリーププロセスが存在します。 、mysql_connect 関数。
2. mysql_connect ショート リンク メソッドを使用してデータベースを開くと、ページ スクリプトが終了すると、各ページで SQL が実行され、MySQL 接続が自動的に閉じてメモリが解放されます。ただし、依然として多数のスリープ プロセスが存在します。Web サイトに次の問題があるかどうかを確認できます。
A. ハードディスク上に多数の静的ファイルが存在するか、WEB サーバーの負荷が高くなりすぎて、HTTP リクエストに対する応答が遅くなる可能性があります。これにより、スリープ プロセスが大量に発生する可能性があります。 WEB サービスのパラメータとファイルを適切に調整し、やみくもに静的または Web コンテンツをキャッシュすることは万能薬ではありません。
B、Web スクリプトでは、一部の計算とアプリケーションに非常に時間がかかる場合があります。たとえば、0 秒でデータベースを開いて SQL コードを実行した後、Web スクリプトは複雑な操作を実行するか、A を要求するのに 20 秒かかります。この時点で MySQL バックグラウンドで見られたプロセスでは、MySQL はこの 20 秒のプロセス中は何もせず、ページが完了するまで常にスリープ状態でした。実行するか、wait_timeout 値に達する (強制的に閉じられる) 場合は、Web ページのスクリプトを最適化して、プログラムをできるだけ早く実行するようにするか、mysql_close を実行して、この時間のかかる実行プロセス中に現在の MySQL リンクを強制的に閉じます。
C、収集ステーションでは、MySQL の多数のスリープ プロセスの現象が特に顕著です (たとえば、多くのネチズンが DeDeCMS の MySQL の多数のスリープ プロセスについて質問しました)。これは、ほとんどのコレクター ページにプレ- 操作中に MySQL リンクを開いて (おそらくユーザー権限などを確認するため)、リモート サイトのアクセス速度が遅すぎる場合は、file_get_contents などの操作を開始します。たとえば、Web ページを取得するのに 10 秒かかります。 回答、現在の収集スクリプト プログラムはここでブロックされており、MySQL は何も行わずにスリープ状態になっています。解決策は上記と同じです。file_get_contents を発行してリモート Web ページを収集する場合は、mysql_close を使用して MySQL 接続を強制的に閉じ、収集が完了するまで待ってから、必要に応じて再度 mysql_connect を実行します。

以上がphpとmysqlでsleepの空接続処理を減らす方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。