web-dev-qa-db-ja.com

UbuntuのMySQLは非常に高いIOWAIT

誰かが私のセットアップで何が起こっているのかアドバイスできますか？私はubuntuにmysqlサーバーを持っており、定期的に非常に高いiowaitを生成します。 10〜20分までの長い時間。この間、システムとデータベースはほとんど利用できません。このデータベースを使用するとハングするだけです。この期間中にvmstatを確認したところ、以下のような数値が表示されています

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1 22      0  34712   8260 583416    0    0   660   935   76   99  6  2 84  6
 0 25      0  34560   8280 582932    0    0 42360 27008 2304 1804  9  3  0 84
 0 29      0  34560   8320 583676    0    0 41160 21524 2360 1763  4  4  0 92
 3 20      0  35912   8328 581532    0    0 12940  6856  766  764  1  0  0 99
 1 30      0  34512   8348 581804    0    0  4532  3748  925 1373  4  4  0 92

だからiowaitは大きいです。 innodbプール用に4GBが構成され、サイズが約6〜8GBのデータベースを持つMYSQLがスワップしていると推測しています。この間、dfを使用すると、ルートドライブがほぼいっぱいになり、95％が表示されました。数分でmysqlを再起動すると、再起動し、すべてが正常に戻りました。そして、ルートドライブ（10GB）のスペースは25％に戻りました。 Amazonec2のebsデバイスでmysqlを実行しています。

私のオプションは何ですか？ボックスはubuntu10.4の8GBの大きなインスタンスです。

私はすでに数週間グーグルでそれを解決しようとしていたので、どんな助けにも感謝します。ありがとう

linuxubuntumysqliowaithangs
2
user330026

これは大量のディスクI/Oです。

Iotopを使用して、I/O（バックアップ）を生成しているものを確認することをお勧めします。 mysql processlist はあなた（私たち？）にさらなる手がかりを与えるかもしれません。また、dbmsに対して mysqltuner.pl を実行してみてください。

2
symcbean

クラウドプロバイダー（Amazonではない）でも同様の問題が発生しました... sysbenchでディスクパフォ​​ーマンスを確認するためのベンチマークを作成しました

ゴールドクラウドはSANストレージ...

SRV1 (gold)
Read 0b  Written 10Gb  Total transferred 10Gb  (53.76Mb/sec)
Read 10Gb  Written 0b  Total transferred 10Gb  (22.627Mb/sec)

SRV2 (gold)
Read 0b  Written 10Gb  Total transferred 10Gb  (58.654Mb/sec)
Read 10Gb  Written 0b  Total transferred 10Gb  (21.617Mb/sec)

その後、サーバーを、共有SASディスクを使用するシルバークラウドと呼ばれるものに移行しました。

SRV1 (silver)
Read 0b  Written 10Gb  Total transferred 10Gb  (106.12Mb/sec)
Read 10Gb  Written 0b  Total transferred 10Gb  (78.24Mb/sec)

SRV2 (silver)
Read 0b  Written 10Gb  Total transferred 10Gb  (103.67Mb/sec)
Read 10Gb  Written 0b  Total transferred 10Gb  (98.747Mb/sec)

前後の私のmysqlバックアップ：

バックアップ開始時間6月24日金曜日2:20:02 BRT 2011

バックアップ終了金曜日6月24日:07:01 BRT 2011

バックアップ開始時間6月25日（土）2:20:02 BRT 2011

バックアップ終了土6月25日2:36:44 BRT 2011

0
Marcelo Bittencourt

おかげで、みんな、より多くのメモリの問題がほとんど消えたように見えます、1日1回だけ短いIOWAIT。答えはより多くのメモリだと思います。 –user330026今すぐ編集

0
user330026