[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

GA

2015/02/12

innodb_fast_shutdownとInnoDBの停止/起動にかかる時間とか

InnoDBの停止にやたら時間がかかる、と相談された時に調べたものメモ。

残念ながら試したのはMySQL 5.1.60の ビルトインInnoDB なので、InnoDB PluginやMySQL 5.5以降なら違う結果が出るかも知れない。

まずそもそも、innodb_fast_shutdownの振る舞いについて。
MySQL :: MySQL 5.1 Reference Manual :: 14.6.7 InnoDB Startup Options and System Variables


InnoDBは停止/起動時に大まかに3つのことをやっていて、
  1. InnoDBログのフラッシュ
  2. InnoDBバッファプールのダーティーページをibdata1にフラッシュ
  3. ibdata1からのパージとインサートバッファのマージ(普段完全に非同期でやってるやつ)

これをそれぞれ停止/起動時のどこでやるかをinnodb_fast_shutdownの値で制御できる。

innodb-fast-shutdown InnoDBログのフラッシュ ダーティーページのフラッシュ バックグラウンド非同期処理
0 シャットダウン時 シャットダウン時 シャットダウン時
1(default) シャットダウン時 シャットダウン時 次のスタートアップ以降、非同期
2 シャットダウン時 次のスタートアップ時(クラッシュリカバリー) 次のスタートアップ以降、非同期


InnoDBログファイルさえ適切にフラッシュされていれば一貫性は保障されるので、トラフィック流したままinnodb_fast_shutdown= 2の状態で停止しても一貫性は変わらない。もしそれでロストするとしたらInnoDBのバグだ。

さて、これでテキトーにDirty pageを増やしたあとにinnodb_fast_shutdownの値を比べてみる。

# ./tpcc_start -w 200 -r 0 -l 900 -c 1 -u tpcc -d tpcc -p test ; ps auxww | grep mysqld ; mysql -Ee "show engine innodb status" | grep -i modified ; time mysqladmin shutdown


結果はこんな感じ。ちなみに物理メモリーは1GB割り当てなので、innodb_buffer_pool_size= 1Gするとたぶんページキャッシュほとんど食われてる。

innodb-buffer-pool-size innodb-fast-shutdown Dirty Pages shutdown-time startup-time
1G 0 25103 4:17 0:01
1G 1(default) 24796 1:10 0:01
1G 2 24700 0:01 4:18

シャットダウンと起動にかかる時間を足すと、1 >> 0 == 2という感じ。0と2がほぼ同じなのは直感的に判るとして(シャットダウンの時にやるのを起動時に回しているだけだから…という。↓間違ってるんだけどねこの直感)、1が頭ひとつ飛び抜けている。

これには罠があって、0と1の差である「パージとインサートバッファのマージ」は、起動時にまた非同期で走るのだ。というわけで、innodb_fast_shutdown= 1で停止した後に起動すると、しばらくの間I/Oが走りまくる(非同期でパージとマージを再開する)ので、これを完全に待つとなると話はまた変わってくるはず。つまり、2もその分を加味すれば0より遅いはず。


あと、「InnoDBバッファプールをswap outさせた時にどうなるか」というのも調べないといけなかったのでそれも。
割り当てメモリーは1GBしかないので、10GBの割り当てはモロにswapに行っている(いや、Free Pagesも残ってるけれど)

innodb-buffer-pool-size innodb-fast-shutdown Dirty Pages shutdown-time startup-time
10G 0 49716 11:45 0:03
10G 1 49767 7:22 0:04
10G 2 49067 0:01 3:30


こっちは 2 >> 1 >> 0。

0と1は「ダーティーページをフラッシュするためにバッファプールをスキャンしないといけない」ので、バッファプールをスキャンするためにスラッシングが発生する。2の場合はダーティーページの回復はクラッシュリカバリー処理に任せてしまうので、InnoDBログファイルとibdata1をスキャンして比較すればいいので、起動時に時間がかかるとはいえお釣りが返ってきている…と考えればいいのかなぁ。

大事なことなのでもう一度言います。 MySQL 5.1.60のビルトインInnoDBです

0 件のコメント :

コメントを投稿