MySQLの新しいInnoDB ページI/O圧縮機能について解析してみた
InnoDBにはデータの圧縮機能がありますが、パフォーマンスが低いことからあまり使われていません。ただ今年の Percona Live で Oracle MySQL, MariaDB, そして Percona Server が新しい InnoDB Compression を出してきました。これはFusion-ioの R&D チームがフラッシュストレージ向けの MySQL 高速化の一環で開発したパッチが元になっています。ちなみに私は Fusion-io の社員ですのでこの発表をワクテカして待っていたのですが、折角コードが一般にリリースされたので、ソースコードを眺めて動作を調べることにしました。 参考にしたのは MySQL Server Snapshots (labs.mysql.com) にあるMySQL with InnoDB PageIO Compression のソースコード、およびM
how innodb lost its advantage
For years it was very easy to defend InnoDB’s advantage over competition – covering index reads were saving I/O operations and CPU everywhere, table space and I/O management allowed to focus on database and not on file systems or virtual memory behaviors, and for past few years InnoDB compression was the way to have highly efficient OLTP (or in our case – SGTP – Social Graph Transaction Processing
5.6 以前の InnoDB Flushing
Bind Peek をもっと使おうぜ！(柴田 歩) - JPOUG Advent Calendar 2014(Day 5) -歩 柴田
InnoDBの分離レベルによるMySQLのパフォーマンスへの影響 | Yakst
MySQL Performance Blogの翻訳。MySQLがサポートする4つのトランザクション分離レベルの特徴とパフォーマンス上の特性を、トランザクション履歴の保持方法に的を当てて比較。 January 14, 2015 by Peter Zaitsev 過去数ヶ月に渡って、InnoDBのトランザクション履歴の負債の危険性と、MVCCがMySQLのパフォーマンス問題の原因になりうることについて、いくつかの記事を書いてきた。この記事ではそれに関連して、InnoDBのトランザクション分離レベルとMVCC(multi-version concurrency control、多版型同時実行制御)との関連性、そしてそれらがMySQLのパフォーマンスにどう影響するのかを取り上げてみようと思う。 MySQLのマニュアルにはMySQLでサポートされているトランザクション分離レベルの詳細な説明がある。こ
[Q&A]MySQL開発でやってしまいがちな致命的ミス | Yakst
Percona MySQL Webinarsの発表(MYSQL開発でやってしまいがちな致命的なミスについて)のQAをご紹介します。 本発表はSQLアンチパターン著者のBill Karwinさんの発表です。 オリジナル: http://www.percona.com/resources/mysql-webinars/how-avoid-even-more-common-deadly-mysql-development-mistakes July 17, 2014 by Bill Karwin 水曜日に「MySQLを開発する上でよく起こる(そして致命的な)ミスをどのように回避するか」をPercona MySQL webinarsで発表した。お見逃の際は、ビデオとスライドを見る為に登録すればまだご覧にいただける。 参加いただいた皆様、そしてとりわけすばらしい質問をしていただきありがたく思っている
MySQL InnoDBの圧縮に関する雑感 | Ore no homepage
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
MySQLがオンラインALTER TABLEでOOM Killerに殺されたはなし | GMOメディア エンジニアブログ
こんにちは、DBAです。 MySQL5.6のオンラインALTER TABLEでハマった時のおはなしです。 5.6にはオンラインALTER TABLE関連のパラメーターに innodb_sort_buffer_size というものが追加されており(5.5以前はfast index creationが効く時に使われるパラメーターとして内部的に1Mでハードコードされていたものが、設定可能になった)、前にざっくり試したところ 大きくすれば一応それなりの恩恵は受けられそうなので大きくしたんですよ。 毎日の定期バッチで盛大にInnoDBのテーブルにバルクインサートをかけた後にALTER TABLEでインデックスをくっつけてRENAME TABLEでテーブルを切り替える…なんてことをやっているサービスには打ってつけだと思ったわけです（そもそもそのやり方の善悪について やがて DBAは 考えることを止めた
How to improve InnoDB performance by 55% for write-bound loads
Update: do not do this, this has been proven to corrupt data!During April’s Percona Live MySQL Conference and Expo 2014, I attended a talk on MySQL 5.7 performance an scalability given by Dimitri Kravtchuk, the Oracle MySQL benchmark specialist. He mentioned at some point that the InnoDB double write buffer was a real performance killer. For the ones that don’t know what the innodb double write bu
基本に戻ってInnoDBの話をします
14. mysql> SHOW CREATE TABLE t1G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `num` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `val` varchar(32) DEFAULT NULL, UNIQUE KEY `num` (`num`), KEY `val` (`val`) ) ENGINE=InnoDB AUTO_INCREMENT=100000001 DEFAULT CHARSET=utf8mb4 1 row in set (0.03 sec) 【 innodb_buffer_pool_size= 4G 】 $ time bin/m
Innotop: A real-time, advanced investigation tool for MySQL
GUI monitoring tools for MySQL are not always suitable for all our needs or situations. Most of them are designed to provide historical views into what happens to our database over time rather then real-time insight into current MySQL server status. Excellent free tools for this include Cacti, Zabbix, Ganglia, Nagios, etc. But each of them needs to be properly configured to provide details on what
MySQL 5.6のインストール後にチューニングすべき項目 | Yakst
MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -
(帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ！この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
TokuDB vs InnoDB in timeseries INSERT benchmark
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
MySQLは立ち止まらない・・・MySQL 5.7開発版登場！
まだMySQL 5.6が登場して興奮冷めやらぬところだが、MySQLの開発チームはその手綱を緩めることはない。次期バージョンの開発版であるMySQL 5.7.1がすでに登場している。MySQLの開発リリースモデルではマイルストーンリリースと呼ばれるマイナーバージョンごとに新しい機能が盛り込まれる。（参照：MySQL 5.5登場）MySQL 5.6系での最後のマイルストーンリリース、つまり新しいバージョンが盛り込まれたバージョンがマイルストーン9、そして5.7.1がマイルストーン11となる。（マイルストーン10、つまり5.7.0はリリースされていないバージョンとなっている。）MySQL 5.7が正式版になるまでに、いくつのマイルストーンリリースを経るか、つまりどれだけ新機能が搭載されるかについては今のところ未定だが、新しいバージョンのリリースが待てない！という人はぜひMySQL 5.7.1を
innodb_support_xa と binlog の危ない関係 : DSAS開発者の部屋
昨日の記事 で innodb_support_xa = 0にすると RDS が速くなることを紹介したのですが、その後 Twitter で innodb_support_xa = 0 にするとクラッシュ時だけでなく通常時も binlog とトランザクションログの一貫性が無くなる（コミットする順序が前後する）可能性があることを指摘していただきました。 innodb_support_xa=0すると、トランザクションがコミットされた順番でバイナリログに載ることが保証できなくなるんだけどいいのかな？ DSAS開発者の部屋:AWS RDS の書き込み性能チューニング dsas.blog.klab.org/archives/52108… — ts. yokuさん (@yoku0825) 2013年4月24日 実際に、 MySQL 5.5 と 5.6 両方で、 innodb_support_xa の説明に
MySQL(InnoDB) で "Index column size too large. The maximum column size is 767 bytes." いわれるときの対策 - かみぽわーる
tl;dr: MySQL 5.5.14以降だとinnodb_large_prefixオプションで3072バイトまでインデックス張れる MySQL(InnoDB)では、ひとつのカラムのキープレフィックスの最大値が767バイトという制限があるので、ついうっかりして Index column size too large. The maximum column size is 767 bytes. とか Specified key was too long; max key length is 767 bytes といったエラーを見たことある人は多いのではないかと思います。 よくあるケースだと、varchar(256)以上のutf8なカラムにインデックスを張ろうとするとこのエラーとご対面できます。 CREATE TABLE t (c varchar(256), index (c)); ERROR
開発スピードアクセル全開ぶっちぎり！日本よ、これがMySQL 5.6だッ！！
米国で行われているMySQL Connectというイベントで、ついにMySQL 5.6 RC（リリース候補版）が発表された。リリース候補版ということは、これが次の正式版になるということだ。MySQL 5.5は5.1から凄まじい進化を遂げたバージョンであった。だが、MySQL 5.6はさらにそれを上回る進化を遂げている！正直ここまでの進化を誰が予想しただろうか、いや誰も出来なかったであろう。これまで、α版が出たときから何度か新機能について紹介してきたが、今回改めてMySQL 5.6の新機能を振り返ってみようと思う。すべてまとめるともの凄い内容だ。興奮して夜も眠れなくなること請け合いだ。MySQLの進化が止まるのでは？などという心配は吹き飛び、もはやもうちょっと小出しにしなくて良かったのか？と心配してしまうレベルである。 それではMySQL 5.6の新機能について紹介していこう。 InnoDB
My sql innovation work -innosql
David Jiang presented InnoSQL, a new branch of MySQL that features a flash cache for the InnoDB storage engine. The flash cache provides higher performance than using an SSD as the durable storage alone. It caches both reads and writes using SSDs and employs techniques like merge writes and sequential writes to optimize for SSD performance. Benchmark results showed the flash cache improved through
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Exploring InnoDB page management with innodb_ruby
show innodb status
