web-dev-qa-db-ja.com

崩壊しつつあるMySQLサーバーのiostatを解釈する方法

崩壊し始めたアプリケーション/ MySQLサーバーの組み合わせがあります。現在、1億2500万行のMySQL MyISAMテーブルのコピーでスタックしています（INSERT INTO a_copy SELECT * FROM a with KEYS DISABLED オン a_copy）。複製された本番VMの本番データについて、このクエリが1時間弱の一部であるジョブのベンチマークを行いました。ただし、このジョブを本番環境で実行すると、コピークエリが終了せずに12時間以上実行され、すべてのMySQLクエリが糖蜜よりもランダムに遅くなります（60秒以上、ロックなし）。

Iostatからの出力

yyyy@xxxx:~$ iostat -mxdc 10
Linux 2.6.32-5-686 (xxxx)         12/24/14        _i686_  (4 CPU)

avg-cpu:  %user   %Nice %system %iowait  %steal   %idle
5.24    0.00    1.34   13.43    0.00   80.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               1.84   232.18   68.24  468.50     1.88     2.74    17.62    47.19   87.87   0.69  36.79

avg-cpu:  %user   %Nice %system %iowait  %steal   %idle
0.77    0.00    2.26   27.92    0.00   69.05

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               6.70     6.10  317.30  208.20     1.37     0.83     8.56   140.26  173.99   1.90 100.00

avg-cpu:  %user   %Nice %system %iowait  %steal   %idle
0.81    0.00    2.58   31.64    0.00   64.97

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               5.00    11.50  372.80  242.80     1.56     1.00     8.54   146.50  321.34   1.62 100.00

avg-cpu:  %user   %Nice %system %iowait  %steal   %idle
0.17    0.00    1.65   39.42    0.00   58.76

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               3.00    23.40  226.80  618.00     0.94     2.50     8.34   145.54  171.94   1.18 100.00

avg-cpu:  %user   %Nice %system %iowait  %steal   %idle
0.22    0.00    1.77   32.23    0.00   65.78

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               5.70    22.50  282.10  491.80     1.18     2.02     8.45   145.72  182.10   1.29 100.00

これをどのように解釈すればよいですか？

linuxmysqliostat
1
Henrik Lindberg

私が見つけ、本番環境で解決した最良の解決策は、 http://www.mysqldiary.com/if-you-copy-a-myisam-table-with-primary-key-don%E2）で見つかりました。 ％80％99t-forget-to-order-the-rows-first / 。

SHOW INDEX IN a WHERE Key_name='PRIMARY'を使用して、テーブルの主キーを識別し、クエリにORDER BYを追加します。最終的な解決策はINSERT INTO a_copy SELECT * FROM a ORDER BY aID, aOtherColumnのようになります。ここで、aの主キーは（aID, aOtherColumn）です。

私はそれに完全に満足しているわけではありませんが、それはかなりうまく機能し、何よりも、元のバージョンよりもはるかに優れています。

0
Henrik Lindberg

編集：エラーは正しく識別されますが、この解決策は役に立ちません。 MySQLがADD PRIMARY KEYsの場合、テーブルをINSERT INTO a_copy SELECT * FROM aに類似してコピーします。これにより、同じ問題が再び発生します。このスレッドで私の他の応答を確認してください。

そこで、/var/lib/mysql/<mydb>/a*のファイルサイズを調べて、インデックスファイル（.MYI）のファイルサイズが大幅に増加していることを確認しました。

DISABLE KEYSは、一般に非一意キーのみを無効にし、特に主キーをアクティブのままにします。基本的に、125M行のINSERT INTOは、ディスクへのランダム書き込みとして現れるジョイントPRIMARY KEYへの125Mインデックス挿入をケースに入れました。これは、ディスクで実行できる最もコストのかかる作業です。

したがって、私の解決策は、コピー中にDROP PRIMARY KEYテーブルでa_copyを実行し、コピーが完了したらADD PRIMARY KEYを実行することです。

1
Henrik Lindberg