7月は一回も記事書かなかった。3年くらい前からInnoDBの圧縮をしてみたり止めてみたりって行為を度々しているので、所感についてまとめとく。



2011年頃(MySQL5.1)

容量削減目的で圧縮を試す。

環境

  • CPU: Intel(R) Xeon(R) CPU  E5620  @ 2.40GHz(仮想8コア)×1
  • memory: 24GB
  • storage: ioDrive Duo(2面合わせて600GBくらい。SW RAID0で組む。)
  • OS: CentOS 5.4(kernel: 2.6.18-164.el5)
  • filesystem: xfs(noatime, nobarrier)
  • MySQL: 5.1 innodb plugin
  • Query: ピーク時に更新系が5kqpsくらいだったかなあ…忘れた。
圧縮した結果
  • 容量は半分に削減できた。
  • パフォーマンスはあまり変わらなかった。
  • CPU使用率若干増えた。
  • iowaitあまり変わらなかった。ストレージにフラッシュ使ってるってのもあるかもね。
  • 非圧縮のスレーブに比べて、ピーク時のレプリ遅延が甚だしかった。
    • 更新も参照もマスタに向ける。スレーブはバックアップ取得用と昇格用として、オンライン処理はさせないようにして対処。
今でも圧縮されたままで運用されてる。

2013年頃(MySQL5.5)

同じく、容量削減目的で圧縮を試みる。

環境
  • CPU: Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz(仮想16コア)×2
  • memory: 128GB
  • storage: ioDrive2 1.2TB
  • OS: CentOS 6.2(kernel: 2.6.32-220.17.1.el6.x86_64)
  • filesystem: xfs(noatime, nobarrier)
  • MySQL: 5.5
  • Query: ピーク時に更新系クエリが5kqpsとか。
圧縮した結果
  • 容量は半分に削減できた。
  • パフォーマンスはあまり変わらなかった。
  • CPU使用率若干増えた。
  • iowaitあまり変わらなかった。
  • レプリ遅延しやすくなる現象は5.5でも変わらず
    • スレーブを使わなきゃマスタが耐えられない、さらに遅延が致命的になるサービスだったので、圧縮するのをやめた
まとめ
  • InnoDBの圧縮は容量削減という目的においては非常に効果がある。
  • 圧縮が効率的に行われているかはちゃんと見るべき。
    • select * from information_schema.INNODB_CMPで見れます。
  • スレーブがレプリ遅延しやすくなるので注意。
    • スレーブを使わない運用を検討する。
    • スレーブを使う場合は、どれくらい遅延するのかを計測したうえで、サービスレベルとして更新遅延が許容されるサービスか?を吟味する。
  • パフォーマンスはそれほど変わらない。メモリに乗りやすくなるからパフォーマンスに寄与するというような記事をネットで見かけるが、自分のところではそうでもなかった。
  • 誰か5.6とか5.7でも試してほしい。
おわり

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

Set your Twitter account name in your settings to use the TwitterBar Section.