MySQL InnoDBの圧縮に関する雑感

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あまり変わらなかった。ストレージにフラッシュ使ってるってのもあるかもね。
• 非圧縮のスレーブに比べて、ピーク時のレプリ遅延が甚だしかった。
  
  • 更新も参照もマスタに向ける。スレーブはバックアップ取得用と昇格用として、オンライン処理はさせないようにして対処。

• 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でも試してほしい。