3

これは典型的な質問ではありませんが、私にはアイデアがなく、他にどこに行けばよいかわかりません。これを尋ねるより良い場所がある場合は、コメントで私を指摘してください. ありがとう。

状況

Zend Frameworkを使用するこの Web アプリケーションがあるため、 Apache Web サーバー上のPHPで実行されます。データ ストレージにはMySQLを使用し、オブジェクト キャッシングにはmemcachedを使用します。

アプリケーションには、非常にユニークな使用法と負荷パターンがあります。これはモバイル Web アプリケーションであり、1 時間ごとに cronjob がデータベースを調べて、待機中の情報または実行するアクションがあるユーザーを探し、この情報を (外部) 通知サーバーに送信して、これらの通知をユーザーにプッシュします。ユーザーはこれらの通知を受け取った後、アプリにアクセスして使用しますが、ほとんどの場合、非常に短時間です。1時間後、同じことが起こります。

問題

ここ数週間で、アプリケーションの使用が実際に増え始めました。ここ数日で、これらの通知の送信中および送信後(基本的には 1 時間ごと) に、非常に高い負荷がかかり、アプリケーションの応答時間が 2 倍になることに遭遇しました。サーバーがクラッシュしたり、リクエストへの応答を停止したりすることはありません。サーバーはますます遅くなり、回復するのに 20 分かかることがよくあります - 同じことが 1 時間に再び始まるまで.

大規模な監視 (New Relic、collectd) を実施していますが、何が問題なのかわかりません。ボトルネックが見つかりません。それがあなたの出番です：

何が問題なのか、それを修正する方法を教えてもらえますか?

追加情報

サーバーは、16 コアの Intel Xeon (ハイパースレッディングを備えた 8 コアだと思います) と、Ubuntu 10.04 (Linux 3.2.4-20120307 x86_64) を実行する 12GB RAM です。Apache は 2.2.x、PHP はバージョン 5.3.2-1ubuntu4.11 です。

構成情報が問題の分析に役立つ場合は、コメントしてください。追加します。

グラフ

情報

収集した

ニューレリック

(グラフはgifで申し訳ありませんが、同じ期間ではありませんが、最も重要な情報はそこにあると思います)

4

1 に答える 1

2

問題はほぼ確実にMySQLベースです。最終的なグラフmysql/mysql_threadsを見ると、20：00にスレッド数が200（max_connectionsの設定であると想定）に達したことがわかります。max_connectionsがヒットすると、回復するのに時間がかかる傾向があります。

時間の直前にmtopを使用してMySQLを監視すると、何が起こっているのかを理解するのに役立ちますが、これをインストールできない場合は、を使用できますSHOW PROCESSLIST;。問題が発生する前に、mysqlへの接続を確立する必要があります。現在実行中のプロセスが1つだけで、多くのプロセスがキューに入れられているのがわかるでしょう。これが原因である可能性が最も高くなります。

問題の原因となっているクエリを特定したら、コードを攻撃できます。アプリケーションが実際にどのように機能しているかを理解していなければ、問題のクエリの周りに明示的なトランザクションを使用すると、おそらく問題が解決するだろうと思います。

幸運を！

于 2012-04-15T00:41:23.317 に答える