![MariaDB / MySQLで低速クエリをデバッグする](https://linux33.com/image/78427/MariaDB%20%2F%20MySQL%E3%81%A7%E4%BD%8E%E9%80%9F%E3%82%AF%E3%82%A8%E3%83%AA%E3%82%92%E3%83%87%E3%83%90%E3%83%83%E3%82%B0%E3%81%99%E3%82%8B.png)
MariaDBサーバーを設定し、すべてがうまく動作しています。ほとんどのクエリは20ミリ秒未満で実行されますが、クエリは0.5秒以上(時には数秒)かかることがありますが、その理由はありません。 。
0.5秒を超える遅延はそれほど長い遅延のように見えないかもしれませんが、同様のクエリを実行するとまったく目立つ遅延なしに完了するため、クエリ自体に欠陥がないようです。遅延クエリを追跡するためにこれを使用していますが、遅延slow_query_log
クエリのロック時間は1ms未満で、インデックスは短いキー長を使用し、影響を受ける行はほとんどありません。
私の設定はUbuntu Server 14.04とMariaDB 10.0.22で、ほとんど在庫です。後でレプリケーションを設定できるようにバイナリロギング(混合モード)を有効にしましたが、無効にする際に問題も見つかりました。データベースは、同じサーバー上で実行される影響が少ないPHPアプリケーションのデータを格納しますが、数十を超える同時接続を受信できません。これらの接続は単一のテーブルに影響を与える可能性がありますが、同じ行には影響しません。私のテーブルはすべてInnoDB(私が考えるMariaDBの上にあるXtraDB)なので、ロックは問題にならないでください。遅いクエリログはそれをサポートしているようです。
遅延クエリはすべて、UPDATE
短い(整数)主キーを使用する単一行のクエリでした。クエリの1%しか遅延されていませんが、一日中定期的に実行されるクエリがたくさんあります。すべてのフィールドは固定長です(BLOBまたはテキストフィールドはなく、整数および短いvarcharのみ)。
キャッシュされていないテーブルなどを処理してもその理由がわからないため、相対的な時間差(<20ms~3s+)により混乱します。また、他のプログラムではパフォーマンスが著しく向上しません。毎日のバックアップを実行すると、時々少し遅くなりますが、これらのバックアップは一定の時間に実行されますが、遅いクエリは一日中発生します。関連性がある場合に備えて、HHVMを使用してPHPスクリプトを実行していますが、メモリとCPU使用率は通常のPHPよりはるかに安定しており、パフォーマンスも優れています(遅いクエリのために遅れていない場合)。明らかな犯人がいるようではありません。 MariaDBと同じ優先順位なので、間違いなく数秒の遅延ではありません。
これをデバッグするためにできることは他にありますか?調整する必要があるMariaDB設定はありますか?
[編集] Rui F Ribeiroの要求に応じて、以下はいくつかの追加の統計であり、非常に使用量が非常に低いかなり平均的なサーバーです。
free -m
:
total used free shared buffers cached
Mem: 993 768 225 8 83 304
-/+ buffers/cache: 380 613
Swap: 0 0 0
vmstat
:
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 231752 85788 311716 0 0 15 38 30 32 0 0 99 1 0
uptime
:
12:12:24 up 11 days, 21:32, 1 user, load average: 0.11, 0.08, 0.06
sudo /etc/init.d/mysql status
:
* /usr/bin/mysqladmin Ver 9.1 Distrib 10.0.22-MariaDB, for debian-linux-gnu on x86_64
Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.
Server version 10.0.22-MariaDB-1~precise-log
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/run/mysqld/mysqld.sock
Uptime: 1 day 16 hours 23 min 23 sec
Threads: 1 Questions: 32381 Slow queries: 1089 Opens: 92 Flush tables: 5 Open tables: 17 Queries per second avg: 0.222
mysql
最後の再起動以降、遅いクエリの数が1%を超えたようです(平均が大幅に増加したため)。また、PHPのMySQLiインタフェース(より少ない数のオープンを考慮する必要がある)を介して継続的な接続を使用していることも注目に値します。そのため、継続的に接続するとロックなどが自動的に解除されます。