同社は米国に仮想ホストでホストされている複数の Web サイトを運営していますが、ほぼ毎日、サーバー上の mysql サービスが突然ハングアップし、しばらくすると回復します。これは、CPU 使用率の制限を超えて自動的に終了した可能性があります。しかし、実際にはこのサーバー上のトラフィックはほとんどありません。そこで私は以前、サーバープロバイダーのインドのアサンのカスタマーサービスに連絡して、他のユーザーがあまりにも多くの問題を引き起こして全員を一緒に死なせたかどうかを確認した後、アサン人たちは自分たちの問題ではないことを確認するために毛むくじゃらの胸をなでると誓った。 、事態は解決しない。これは問題ではないので、自分で確認する必要がありました。幸いにも、information_schema ライブラリにアクセスできました。調べてみると、mysql ユーザーの 1 人が、busy_time などの指標を非常に高くしていることが分かりました。幸いなことに、Ah San はそれに気づきませんでした。そこで早速プログラムを確認してみましたが、以前のWebサイトのプログラムは私が作ったものではありませんでしたが、アーキテクチャから実装まで多くの問題があることはわかっていましたが、コードはそれほど多くはありませんでした。 HTML は全部見ても死ぬほどではなかったし(特に MVC の素晴らしさを感じた)、とにかくトラフィックが少なかったので普通に動かすだけで十分だった。
mysql は負荷が大きいので、まずこれを見つけて、my.ini に変更して追加します。 "d:/temp/mysql_slow.log"
long_query_time=1
このディレクトリはすでに存在している必要があります。 mysql サービスを再起動すると、記録できるようになります。 SQL レコードを確認したところ、どのページにも数十、最大で数千ものクエリがあったことに驚きました。
フォーラムを例に挙げると、1 ページのデータベース クエリの数はわずか 10 回であり、キャッシュを使用するとさらに少なくなる可能性があります。こうやって計算すると、本来の負担の数十倍に相当します。
何百ものクエリを書き留める忍耐力のある人はいないので、循環クエリになるはずです。 SQL ステートメントでもこれが示されています。理由がわかれば、関連するページを見つけてループ クエリを変更するのは簡単です。たとえば、すべての地域カテゴリとそのカテゴリの記事数を無視するページがあります。プログラムに関する限り、おそらく次のようになります
コードをコピーします
コードは次のとおりです:
$sql1="SELECT aid,count(*) as cc FROM pz_content WHERE uid=$uid group by aid";
$rs1=$ db->query($sql1);
if(is_array($rs1)){
foreach($rs1 as $r1){
出力...
echo id2name($r1->aid); } } ...... function id2name($aid)
{
$sql="pz_area_a から ename を選択where aid_a=".$id;
$result=mysql_query($sql);
$row=mysql_fetch_object($result);
return $row->ename;
}
コードのフォールトトレランスに関係なく実装からわかるように、ユーザーは最初にユーザーの関連記事を読み、地域 ID によって処理を進めます。グループ化とカウントが行われ、地域ごとに地域名が出力されます。したがって、地域が 10,000 ある場合、クエリは 10,000 件になります。ここで行われました。タイミング コードを入力して調べてみると、約 6M のメモリを消費し、実行に 16 秒かかり、合計 1001 個のクエリがありました。実際、これは 1 文の SQL で実行できます。ループは必要ありません。
コードをコピー
コードは次のとおりです:
$sql1="select pz_area.aid,pz_area.ename,tb1.cc from pz_area right join (SELECT helps,count(*) as cc FROM pz_content WHERE uid= $uid group by aid) as tb1 on pz_area.aid=tb1.aid";
$rs1=$db->query($sql1);
if(is_array($rs1)){
foreach($ rs1 as $ r1){
出力...
Echo $r1->ename
}
;
問題は解決されます。再実行後のメモリ消費量はほぼ同じですが、1 つのクエリの CPU 実行時間はわずか 647 ミリ秒で、元のクエリよりも 26 倍悪くなっています。改めて見てみると、pz_content テーブルにはかなり多くのレコードが含まれていることがわかりました。クエリや地域ごとの分割が頻繁に行われますが、インデックスがないことがわかりました。補助するインデックスを追加すると、実行時間は 432 ミリ秒に短縮されます。
このページのことは忘れて、ここでやめて次回に続けましょう。
http://www.bkjia.com/PHPjc/322364.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/322364.html技術記事同社は米国の仮想ホストでホストされている Web サイトをいくつか持っています。サーバー上の mysql サービスがほぼ毎日ある時点で突然ハングアップし、しばらくすると回復するのではないかと思います...
。