MySQLの更新クエリがすべてのデータベースで遅くなりました

Question

私は、約5人のクライアントが2番目のPHPスクリプトに接続する通常のLAMPスタックを実行しているubuntuサーバー（2x 3.0Ghzクワッドコア、16GBラム、15k sasドライブ上のRAID 1）を持っています。クライアントは小さな情報を伝え、そのデータはMySQLデータベースで更新されます。

サーバー上のバックグラウンドでは、データを1秒に1回見直してデータベースを更新するPHPスクリプトがあります。

重複して更新され、挿入されていないレコードが2つしかないため、テーブルサイズは本当に小さい（最大4行）。

しかし、私は通常、バックグラウンドスクリプトが実行される速度を見ながらsshセッションを開いています。約100マイクロ秒（.0001秒）のSELECT（SELECT）とUPDATE（UPDATE）クエリーを一気に実行した後、突然UPDATEはどのデータベースに関係なく、クエリごとに20000マイクロ秒（.02秒）私はすべてのデータベースを削除しました（システムデータベースではなく作成したものだけ）、クライアントをブロックし、コンソールmysqlとPhpMyAdminからクエリを実行しました。結果は次のようになります。同じ。ここで

は、無負荷またはサーバに接続されたクライアントとのコンソールから実行、例です。

mysql> CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET utf8 */; 
Query OK, 1 row affected (0.00 sec) 

mysql> CREATE TABLE `test` (
    `idtest` int(11) NOT NULL AUTO_INCREMENT, 
    `field1` varchar(64) NOT NULL, 
    `field2` varchar(64) NOT NULL, 
    `field3` int(11) NOT NULL, 
    PRIMARY KEY (`idtest`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 
Query OK, 0 rows affected (0.14 sec) 

mysql> INSERT INTO `test`.`test` (`idtest`, `field1`, `field2`, `field3`) VALUES (NULL, 'Testing', 'None', '0'); 
Query OK, 1 row affected (0.02 sec) 

mysql> SELECT * FROM test; 
+--------+---------+--------+--------+ 
| idtest | field1 | field2 | field3 | 
+--------+---------+--------+--------+ 
|  1 | Testing | None |  0 | 
+--------+---------+--------+--------+ 
1 row in set (0.00 sec) 

mysql> UPDATE `test`.`test` SET `field3` = '1' WHERE `test`.`idtest` = 1; 
Query OK, 1 row affected (0.03 sec) 
Rows matched: 1 Changed: 1 Warnings: 0 

上記の例から、また、INSERTが影響され表示されます。上記の同じクエリを別のサーバーでリソースの約1/10で実行し、予想通り100〜200マイクロ秒でクエリを実行します。私はそれがInnoDBキャッシュと関係があると思うが、間違っている可能性がある。

負荷平均：負荷平均：0.04、0.04、0.05

サーバー：ここ

は、サーバーとMySQL上のいくつかの情報であるローカルホストUNIXソケット経由

サーバーの種類：MySQLの

サーバーバージョン：5.6.28-0ubuntu0.15.04.1 - （Ubuntu）

プロトコルバージョン： 10

ユーザー：ルート@ localhostの

サーバの文字セット：UTF-8のUnicode（UTF8）

と

mysql> SHOW VARIABLES LIKE '%query%'; 
+------------------------------+-----------------------------------+ 
| Variable_name    | Value        | 
+------------------------------+-----------------------------------+ 
| binlog_rows_query_log_events | OFF        | 
| ft_query_expansion_limit  | 20        | 
| have_query_cache    | YES        | 
| long_query_time    | 10.000000       | 
| query_alloc_block_size  | 8192        | 
| query_cache_limit   | 1048576       | 
| query_cache_min_res_unit  | 4096        | 
| query_cache_size    | 16777216       | 
| query_cache_type    | OFF        | 
| query_cache_wlock_invalidate | OFF        | 
| query_prealloc_size   | 8192        | 
| slow_query_log    | OFF        | 
| slow_query_log_file   | /var/lib/mysql/xxxxx-slow.log | 
+------------------------------+-----------------------------------+ 
13 rows in set (0.00 sec) 

と

mysql> SHOW VARIABLES LIKE '%cache%'; 
+--------------------------------+----------------------+ 
| Variable_name     | Value    | 
+--------------------------------+----------------------+ 
| binlog_cache_size    | 32768    | 
| binlog_stmt_cache_size   | 32768    | 
| have_query_cache    | YES     | 
| host_cache_size    | 279     | 
| innodb_disable_sort_file_cache | OFF     | 
| innodb_ft_cache_size   | 8000000    | 
| innodb_ft_result_cache_limit | 2000000000   | 
| innodb_ft_total_cache_size  | 640000000   | 
| key_cache_age_threshold  | 300     | 
| key_cache_block_size   | 1024     | 
| key_cache_division_limit  | 100     | 
| max_binlog_cache_size   | 18446744073709547520 | 
| max_binlog_stmt_cache_size  | 18446744073709547520 | 
| metadata_locks_cache_size  | 1024     | 
| query_cache_limit    | 1048576    | 
| query_cache_min_res_unit  | 4096     | 
| query_cache_size    | 16777216    | 
| query_cache_type    | OFF     | 
| query_cache_wlock_invalidate | OFF     | 
| stored_program_cache   | 256     | 
| table_definition_cache   | 615     | 
| table_open_cache    | 431     | 
| table_open_cache_instances  | 1     | 
| thread_cache_size    | 8     | 
+--------------------------------+----------------------+ 
24 rows in set (0.00 sec) 

my.cnfファイル：

[mysqld] 
innodb_autoinc_lock_mode=0 

そして最後に：

ubuntu@xxxxx:~$ df 
Filesystem      1K-blocks Used Available Use% Mounted on 
udev        8202368  0 8202368 0% /dev 
tmpfs       1642808 9600 1633208 1% /run 
/dev/mapper/xxxxx--vg-root 53035144 7827988 42490076 16%/
tmpfs       8214020  0 8214020 0% /dev/shm 
tmpfs        5120  0  5120 0% /run/lock 
tmpfs       8214020  0 8214020 0%  /sys/fs/cgroup 
/dev/sda1       240972 112893 115638 50% /boot 
tmpfs       1642808  0 1642808 0% /run/user/1000 

任意のアイデア？ヘルプのために事前にありがとう！

更新編集：

は問題の非常に奇妙と突然発症を考えると、私はそれは、ハードウェア関連している可能性が疑われ始めています。

私は完全にサーバーからMySQLをパージしてリポジトリから再インストールしましたが、状況に影響はありませんでした。私はPerk6iで2台の15k sasドライブを使用してRAID 1を実行しています - ここから始めます。これは、StackOverflowよりも多くのServerFaultの問題を終了する可能性があります。もっと掘り下げた後、私は報告します。

Answer 1

それはちょっと長い時間がかかり始めた場合、いくつかのことが思い浮かぶ。

ロックを解除するメカニズムのように、同時の更新を実装するために使用される可能性があるような明白なことについては言及しません。

ここでは、単一間接ブロックアドレッシングではなく、間接ディスクブロックアドレッシングを必要とするファイルサイズのしきい値を超えていることを示します。これは、論理シーケンスで次のディスクブロックをフェッチする個々の呼び出しがそれほど遅くなることを意味します。すべての単一の実際のI/Oに対してペナルティが課せられます。私は、ディスク・ブロック・ハッシュ・キューに出て行く何かのような、実際のI/Oを参照しています。これはread（）と言うだけではなく、すでにプリフェッチされたデータを引き出すことにもなります。最後のディスクI/O

これは単なる推測です。

実際には約20,000 usec = 0.2 msecですか？

Answer 2

更新速度を向上させる場合は、char instead of varcharフィールドを使用し、where句で比較するフィールドにunclustered indexesを作成することを検討してください。

また、更新クエリでメカニカルハードドライブを使用している場合は、spin up timeが結果に影響する可能性があるため、1つのクエリを実行して更新速度を測定しないでください。 Windowsはデータベースファイルをキャッシュし、ラムからデータを提供することもできます。スピンアップ遅延をテストするには、スーパーフェッチサービスとrun loopsを無効にします。