2

percona サーバー 5.5.32-31.0 を仮想化しようとしているところですが、何かおかしいと思います。仮想化されたボックス挿入 (実際にはすべて) では、クエリは遅くなりますが、応答時間を大幅に短縮するのはプロファイルの「クエリ終了」ステップです。

一歩戻ってみましょう。これが私のテスト テーブルです。

CREATE TABLE `mysql_io_test` (
  `id` int(11) NOT NULL,
  `time_diff` char(8) COLLATE utf8mb4_unicode_ci NOT NULL,
  `data` char(100) COLLATE utf8mb4_unicode_ci NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

これを実行する：

set profiling = 1;
insert into util.mysql_io_test select 999, '99:99:99', 'ABCDEFGHIJ';
set profiling = 0;

私は得る：

starting, 0.000031
checking permissions, 0.000005
Opening tables, 0.000530
System lock, 0.000008
init, 0.000008
optimizing, 0.000002
executing, 0.000095
end, 0.000005
query end, 0.067226
closing tables, 0.000013
freeing items, 0.000039
logging slow query, 0.000002
cleaning up, 0.000005

仮想化されていないボックス (古いデータベース: v5.5.27-28.1) では、より合理的な結果が得られます。

starting, 0.000039
checking permissions, 0.000004
Opening tables, 0.000013
System lock, 0.000009
init, 0.000008
optimizing, 0.000002
executing, 0.000038
end, 0.000003
query end, 0.000143
closing tables, 0.000008
freeing items, 0.000018
logging slow query, 0.000001
cleaning up, 0.000002

これらの各ステップの真の意味についてはあまり詳しくありませんが、「クエリの終了」が遅くなる理由がまったくわかりません。マニュアル ( http://dev.mysql.com/doc/refman/5.5/en/general-thread-states.html ) には、これ以上の情報はありません。明日、古いバージョンにロールバックしてコードを掘り下げてみますが、誰かがこれを以前に見たことがあり、この謎に光を当てることができるかもしれないと思いました.

役に立つかもしれない他のいくつかのこと：

  • VM は、古いものとほぼ同じくらい強力なボックスで実行されています。どちらも中距離です。
  • 現在、ボックスで実行されている他の 6 つの VM があります。
  • このサーバーは一般的に古いサーバーよりも低速です
  • 新しいサーバーでのいくつかの大規模な負荷テストはひどいものでしたが、最新のものは実際には古いサーバーよりも高速でした. したがって、この「クエリ終了」の問題が常に発生しているとは言えません。ただし、前回の大規模なテスト以降、構成は変更されています。
4

1 に答える 1

0

これに遭遇した他の人にとっては、問題を少し追跡したと思います。mysql が次の警告を出していたため、innodb_flush_method を通常のボックスの ALL_O_DIRECT から VM の O_DIRECT に変更しました。

kernel: EXT4-fs (vdb1): Unaligned AIO/DIO on inode 17565314 by mysqld; performance will be poor.

ALL_O_DIRECT に戻すと、その警告が再び表示され始めますが、「クエリの終了」ステップでのパフォーマンスが 100 倍向上するので、今はそのまま使用します。

これが同じ問題に遭遇した他の人に役立つことを願っています。

于 2013-08-23T17:40:15.310 に答える