0

アプリケーションは、すべてのクエリ (選択、更新、挿入) でアクセス速度を必要とするリアルタイム サイトです。低レイテンシは、すべてのクエリで 200 ミリ秒未満でなければなりません。

まあ、平均で各クエリの 98% です。ジョブ クエリが完了するまでの時間は 0.001 ～ 0.005 秒未満です。

問題は、1 時間に約 5 回、最大で 1 秒かかる場合があり、5 秒になることもあります。問題の本当の原因はわかりません。

INNODB から MEMORY に移動することで、問題を軽減できることがわかりました。

質問は、クエリに最大 5 秒かかる場合があるのはなぜですか?

Example query in sometime query more than 1 secound

# Time: 130328 20:27:40
# User@Host: ferge572w[ferge572w] @ localhost []
# Query_time: 1.339712  Lock_time: 0.000026 Rows_sent: 0  Rows_examined: 1
SET timestamp=1364477260;
UPDATE log_product SET credit=credit+1 WHERE id_product='149721921' and id_user='2029275' LIMIT 1;

table index: id_product, id_user
No.row: 33,491   table size: 5Mb

# Time: 130329  7:25:37
# User@Host: ferge572w[ferge572w] @ localhost []
# Query_time: 1.439856  Lock_time: 0.000031 Rows_sent: 0  Rows_examined: 1
SET timestamp=1364516737;
UPDATE product SET lastuser='hello',picperson='1',lastid='2030505',country='thailand',price=price+0.01,time=DATE_ADD(time, INTERVAL 3 SECOND) WHERE id='349721227' LIMIT 1;

table index: id
No.row: 35   table size: 2.1Mb

EXPLAIN を使用してクエリを最適化し、インデックスを更新するようにします。テーブルのフィールドのデータ型とその長さもチェックしましたが、まだ問題があります

更新問題の原因は、システムの IOwait が高い場合です。遅いクエリ heppen Immediate。修正方法

IO 待機が高い場合、クエリが遅くなります。

iotop コマンドから表示

-- TID -- PRIO -- ユーザー -- ディスク読み取り -- ディスク書き込み -- SWAPIN -- IO> -- コマンド

-- 2311 -- be/4 -- mysql -- 0.00 B/s -- 0.00 B/s -- 0.00% -- 96.25% -- mysql~l.sock

-- 2311 -- be/4 -- mysql -- 0.00 B/s -- 0.00 B/s -- 0.00% -- 96.25% -- mysql~l.sock

-- 2311 -- be/4 -- mysql -- 0.00 B/s -- 0.00 B/s -- 0.00% -- 96.24% -- mysql~l.sock

午後 6:13:28 ～ 午後 6:13:29 に高 IO 待機開始 (sar コマンド)

--------------------- CPU -- %usr -- %nice -- %sys -- %iowait -- %steal

-- 午後 6:13:28 --- すべて -- 2.53 -- 0.00 -- 2.02 -- 39.39 -- 0.00

-- 午後 6:13:29 --- すべて -- 1.99 -- 0.00 -- 1.00 -- 49.25 -- 0.00

その間に遅いクエリを取得しました

時間: 130329 18:13:29

ユーザー@ホスト: wdwdwd[wdwdwd] @ localhost []

Query_time: 2.007902 Lock_time: 0.000025 Rows_sent: 0 Rows_examined: 1 SET タイムスタンプ = 1364555609;

UPDATE log_product SET credit=credit+1 WHERE id_product='349721228' and id_user='2021841' LIMIT 1;

4

4 に答える 4

3

いくつかの理由が考えられますが、より多くのデータを持っている (そしてチェックしている) ほど、答えを見つけるのに近づきます。

確認事項:

  • 共有ホスティングを使用している場合、信頼できない可能性があります。
  • MySQLのスローログを確認しましたか
  • クエリに対して mysql Explain を実行しましたか?
  • SQL クエリが遅すぎるときに大量のリクエストを受け取っていますか? ディスク IO が問題になる可能性があります
  • テーブルを最適化する必要がありますか?
  • マシンのメモリが不足していませんか?

http://newrelic.com/は、これらの状況で非常に役立ちます (利用できる無料バージョンがあります)。

考えられる理由:

  • ディスク I/O: 共有ホスティングを使用しているか、サーバーのディスクが
    信頼できない/飽和している場合があります
  • ピーク使用量: 特定の時間に大量のトラフィック/クエリが発生して遅延が発生する
  • その他のサーバー関連のスローダウン: 例: AntiVirus または別のプロセスが実行され、リソースを消費しています

私や他の人が示唆しているように、データをさらに分析することができれば、特定の問題の根底にたどり着くのに非常に価値があることが証明される可能性があります

于 2013-03-29T05:09:01.277 に答える
2

大きなデータベースでは、常にいくつかの点に注意してください。

  1. mysql のスロー クエリ ログを確認する
  2. 更新時にインデックスを RDBMS で再度管理する必要があるため、インデックスを確認します。
  3. 適切なデータ型ではパフォーマンスの問題も発生する可能性があるため、テーブルのフィールドのデータ型とその長さを確認してください。
  4. EXPLAIN を使用してクエリを最適化する
  5. アプリケーション要件に従って適切なストレージ エンジンを選択する
于 2013-03-29T05:14:19.867 に答える
0

そのような変化の結果は、ネットワークの性質を持っている可能性があります。例のために。Windows ホストでは、「localhost」の代わりに「127.0.0.1」を使用できます。これは、デフォルトで localhost が IP6 アドレスにマップされ、MySQL サーバーに問題があるためです。

于 2013-03-29T05:51:54.640 に答える
0

直接のphp / AJAX呼び出しによる画像/クエリの数、およびページに含まれるJSファイルの数を確認してから、試してください

于 2013-03-29T06:12:24.077 に答える