タグ

innodbとMySQLに関するmasa_matyaのブックマーク (25)

  • SystemTapでMySQL 5.5のDisk I/Oを分析する - SH2の日記

    2010年1月の記事SystemTapでMySQLのDisk I/Oを分析するの続きです。以前作成したSystemTapスクリプトは、実はMySQL 5.5のDisk I/Oを分析することができませんでした。というのも、MySQL 5.5からInnoDBが非同期I/Oを行うようになったのですが、以前のスクリプトは非同期I/Oに対応していなかったためです。日はMySQL 5.5におけるInnoDBの非同期I/Oについて、確認していきたいと思います。 非同期I/Oとは 非同期I/Oとは、I/O処理をブロックされることなしに行う方式のことです。通常のI/O処理はそれが完了するまで待たされてしまうのですが、非同期I/Oを用いることでI/O処理の完了を待つことなしに他の処理を進めることができます。以下のウェブサイトでとても詳しく解説されています。 バッファキャッシュとAIO(1) - O'Reil

  • Real-Life Use Case for "Barracuda" InnoDB File Format

    In one of his recent posts Vadim already gave some information about possible benefits from using new InnoDB file format but in this post I’d like to share some real-life example how compression in InnoDB plugin could be useful for large warehousing tasks. One of our clients had really many problems with one of his servers. This is pretty powerful server (Intel Xeon E5430 / 8Gb RAM / BBU-enabled R

    masa_matya
    masa_matya 2011/08/04
    innodbのrow_formatを変えたらいい感じになったよって話。compressedのベンチマーク結果は、sh2さんの記事を見るのが良い。bug fix見てるとちらほら出てくるから使うか悩みどころ
  • Percona Xtrabackup 1.6.2 released!

    masa_matya
    masa_matya 2011/07/30
    最新安定板がリリースされてた
  • https://blogs.oracle.com/MySQL/entry/comparing_innodb_to_myisam_performance

    masa_matya
    masa_matya 2011/07/22
    inndob_flush_log_at_trx_commit=0 or 2の場合にOS Crashなどがあっても、Crash recovery自体には影響が無くMyISAMより安全
  • InnoDBのリカバリ機能を検証してみる at nkjmkzk.net

    Oracle, Open Source, Privateinnodbはクラッシュ時のリカバリ機能を実装しており、mysqldがクラッシュした場合やOS自体がクラッシュした場合にもしコミットされたデータがテーブルから失われていても再起動時にib_logfileからコミットされたトランザクションを読み出し、それが実データ(デフォルトだとibdata)に反映されていなければ反映させるという処理が走ります。MySQLはinnodb_flush_log_at_trx_commitの値により、1秒毎、またはコミット毎にトランザクションをログファイルにフラッシュします。 今回は以下2点について検証を行いました。 1.クライアント側から発行したクエリがクラッシュ後にどこまで復旧されているか 2.リカバリにかかる時間の測定(ログのファイルサイズとの因果関係にも言及) 1の検証についてはinnodb_fl

    masa_matya
    masa_matya 2011/07/21
    flush_log_at_trx_commitを0,1にした時の検証。やはり0にした時は1秒間に発生したトランザクション数分のデータが失われる。リカバリ時間の違いは0 or 1 によるものというより、リカバリ対象となるトランザクション数によるも
  • How to load large files safely into InnoDB with LOAD DATA INFILE

    Recently I had a customer ask me about loading two huge files into InnoDB with LOAD DATA INFILE. The goal was to load this data on many servers without putting it into the binary log. While this is generally a fast way to load data (especially if you disable unique key checks and foreign key checks), I recommended against this. There are several problems with the very large transaction caused by t

    How to load large files safely into InnoDB with LOAD DATA INFILE
    masa_matya
    masa_matya 2011/04/21
    InnoDBで大容量のファイルをLOADする時、UNDOログの生成などによりI/O性能が劣化。大容量を一度にCOMMTせずに小さく分けたファイルで大量のCOMMITをすることでそれを回避
  • http://onaxer.com/blog/blog/2010/07/29/innodb-the-innodb-memory-heap-is-disabled/

    masa_matya
    masa_matya 2011/03/13
    pluginを起動した時に出てくる" The InnoDB memory heap is disabled "メッセージについて。innodb_use_sys_mallocがONの時表示されるが、問題ない。
  • InnoDBのファイルサイズ管理

    最近、InnoDBのデータ領域(テーブルスペース)が成長してしまって元に戻すことが出来ない場合の対処についてよく質問されるので、今日はテーブルスペースが成長することへの対策について説明しよう。(ここのところMySQLネタが続いているが、Planet MySQL語版を意識しているわけではないのであしからず!!<<ホントかよ?!>俺) InnoDBのテーブルスペースが成長してしまうのは、ズバリ自動拡張しているからである。テーブルスペースに対して何もオプションを指定しないと、デフォルトでは次のような設定と同じテーブルスペースが作成される。 [mysqld] innodb_data_file_path=ibdata1:10M:autoextend サイズは10MBしかないが、自動拡張するのである。自動拡張してしまうと何が問題なのかというと、データが増えた場合にファイルシステムの空き領域を使い切

    InnoDBのファイルサイズ管理
    masa_matya
    masa_matya 2011/03/11
    innodb_file_per_tableを指定すればテーブルごとにテーブルスペースが作成されるため、運用しやすくなる。ただし、この場合でも共有テーブルスペースは作成される。これは消してはならない。
  • MySQL :: MySQL 8.4 Reference Manual :: 17.14 InnoDB Startup Options and System Variables

    Enabling Automatic InnoDB Configuration for a Dedicated MySQL Server

  • MySQL innodb_flush_method = O_DIRECTの検討 - SH2の日記

    MySQL InnoDBのパラメータでinnodb_flush_methodというものがあります。これはUNIX/Linuxにおいてデータファイル、ログファイルの読み書き方式を指定するためのもので、マニュアルの13.6.3. InnoDB Startup Options and System Variablesによると以下の3種類の設定が可能とされています。 無指定(fdatasync):デフォルトの設定です。特別なフラグなしでファイルをオープンし、書き込み時にfsync()を行います。 O_DSYNC:データファイルについてはfdatasyncと同じです。ログファイルについてO_SYNCフラグをつけてファイルをオープンします。 O_DIRECT:データファイルについてO_DIRECTフラグをつけてファイルをオープンします。ログファイルについてはfdatasyncと同じです。 今回はこのパ

    masa_matya
    masa_matya 2011/03/11
    innodb_flush_methodに関する考察。O_DIRECTにするのは、MySQLのメモリ量を意図的に制限したいとき。sh2さんのおすすめはO_DIRECT利用&innodb_buffer_pool_sizeが物理メモリの半分位。もちろん環境・状況によって変更
  • The Art of Work:MySQL InnoDB Pluginのデータ圧縮機能 性能編 - SH2の日記

    MySQL InnoDB Pluginのデータ圧縮機能の続きです。前回はInnoDB Pluginの独自機能であるデータ圧縮の仕組みを解説し、Wikipedia語版のデータが約半分にまで圧縮されることを確認しました。今回はデータ圧縮によって性能がどのように変化するかを、実際にベンチマーク試験を行って見ていきます。 試験の方針 データ圧縮による性能への影響は、以下の二点が考えられます。 メリット:データサイズが小さくなるため、ディスクI/Oが減る デメリット:圧縮・展開の処理が行われるため、CPU負荷が高くなる そこで、これらの特徴がよく分かるように試験パターンを工夫します。Wikipedia語版のデータはInnoDB上でおよそ5GBありますが、まず狭い範囲に絞って読み取り処理を行うことでディスクI/Oがあまり発生しないようにします。これでCPU負荷の傾向を確認することができます。次

    The Art of Work:MySQL InnoDB Pluginのデータ圧縮機能 性能編 - SH2の日記
    masa_matya
    masa_matya 2011/03/10
    compressedによる性能変化の検証。圧縮しなくてもデータが乗る場合は非圧縮に比べ90%、乗り切らなくなってくると350%、圧縮でも乗らない量だと110%の性能となる。CPUコストも高くなる。単に圧縮=>展開をやっているわけでは無
  • MySQL InnoDB Pluginのデータ圧縮機能 - SH2の日記

    InnoDB Pluginの面白い機能の一つに、データ圧縮機能があります。今回はその仕組みと効果について見ていきたいと思います。まずはグラフをご覧ください。 これはWikipedia語版のデータベースをダウンロードし、記事文の格納されているtextテーブルをMySQL 5.1+InnoDB Plugin 1.0の環境にロードしたものです。 元テキスト:今回利用したデータは2009/06/21版のものです(jawiki-20090621-pages-articles.xml.bz2)。元テキストはここからXml2sqlを用いてタブ区切りテキストを取り出したものを用いています。このファイルには1,167,411件の記事が格納されており、容量は3,436MBとなっています。 元テキスト gzip:元テキストをgzipコマンドで圧縮したものです。 MyISAM:記事をMyISAMのテーブルに

    MySQL InnoDB Pluginのデータ圧縮機能 - SH2の日記
    masa_matya
    masa_matya 2011/03/10
    row_formatについての解説もあり。ページサイズはデフォルト8KBだが、これはzlibがデータを半分以下のサイズに圧縮していることを期待しているため。圧縮がうまくkey_block_sizeに収まったかはinformation_schemaのInnoDB_CMPで確認可
  • InnoDB のパフォーマンスチューニング - MySQLカンファレンス2007 - akiyan.com 管理人メモ

    http://www.mysql-ucj2007.jp/details/j25.html 木下 靖文 氏 NTTコムウェア株式会社 プロジェクト管理統括部技術SE部門 DB技術グループ (「InnoDB」は「いんのでーびー」と言うらしい...今まで「いのでーびー」と言ってました) InnoDBをなぜ使うか トランザクション コミット、ロールバック、セーブポイント 外部キー 行レベルロック オンラインバックアップ クラッシュリカバリ クラッシュリカバリ MyISAMはデータ量の増大とともに時間がかかる InnoDBはデータ量の増大との相関がない InnoDBチューニングの王道的アプローチ クエリを改善して全体的に処理効率を上げる データサイズをできるだけ小さく メモリをできるだけ多く積む コミット性能(同期書き込み) innodb_flush_log_at_trx_commit=1,0,2

    InnoDB のパフォーマンスチューニング - MySQLカンファレンス2007 - akiyan.com 管理人メモ
    masa_matya
    masa_matya 2011/03/10
    多用なパラメータについて解説
  • InnoDBのログとテーブルスペースの関係

    InnoDBのデータ領域はログファイルとテーブルスペースという、切っても切れない2種類のファイルから構成されている。ログファイルは名前からするとただのログだから削除しても平気かな?と思って削除してしまうという問題が後を絶たない。そこで、今日はログファイルとテーブルスペースの関係について説明しようと思う。 InnoDBのログファイルは、別名WAL - Write Ahead Logと呼ばれるもので、名前を日語に直すと「前もって書き込んでおくためのログ」とでも呼べるだろうか。InnoDBのテーブルに対して行われた更新は、全ていったんログに書き込まれるのである。トランザクションがコミットされると、innodb_flush_log_at_trx_commit=1が設定されていればログファイルに書き込みが行われる。0または2の場合には、ログバッファと呼ばれる領域にデータが保持される。その後、時間を

    InnoDBのログとテーブルスペースの関係
    masa_matya
    masa_matya 2011/03/10
    innodbのログとinnodb_log_file_size設定値に関して。
  • Real Beat » Blog Archive » [MySQL] MyISAMとInnoDB

    Keep drinking, Keep listening to music, Go fuck yourself 今運用している某システム、MyISAMのある難癖によって非常に辛い目に遭っております。それはもちろんテーブルロック。これはもうMyISAMを選択した時点でどうしても避けては通れない道。そこんところ仕組みをちゃんと理解してないと、MyISAMのほうが速いって言うから選んだのに、なんだよ全然遅いじゃん!っていうか使い物にならないよウワァァァァンみたいなことになりがち。今のシステムでどうやってMyISAMかInnoDBかを分けたのかというと、単純に更新頻度だった。頻繁に更新されるテーブルはInnoDB、そうじゃなければMyISAM。参照が殆どならInnoDBを選択するメリットは何もないと思っていた。が、実は全然そうじゃなかった。 MyISAMが辛いのは、INSERT文実行時にテーブル

    masa_matya
    masa_matya 2011/03/10
    更新頻度だけを軸にMyISAMを選ぶと痛い目を見る。SELECTのREAD LOCKにも注意
  • MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.2.13.7 物理的な行構造

    ロック読み取り (SELECT ... FOR UPDATE および SELECT ... LOCK IN SHARE MODE)

    masa_matya
    masa_matya 2011/02/25
    row_format COMPACTについて
  • DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!

    MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in

    DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!
  • BirdLab | php研究所

    名前 : コメント (2023-05-04 22:41:02) 名前 : コメント (2023-05-04 22:41:01) 名前 : コメント (2023-05-04 22:41:01) 名前 : コメント (2023-05-04 22:41:00) 名前 : コメント (2023-05-04 22:40:59) 名前 : コメント (2023-05-04 22:40:58) 名前 : コメント (2023-05-04 22:40:57) 名前 : コメント (2023-05-04 22:40:56) 名前 : コメント (2023-05-04 22:40:56) 名前 : コメント (2023-05-04 22:40:55) 名前 : コメント (2023-05-04 22:40:54) 名前 : コメント (2023-05-04 22:40:53) 名前 : コメント (2023-

    BirdLab | php研究所
  • 漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。

    InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い(テーブルの行数を保持してる)のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ

    漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
    masa_matya
    masa_matya 2011/02/24
    select count (*) from tbl; の速度改善にはセカンダリインデックスやトリガの利用を検討していく
  • 知って得するInnoDBセカンダリインデックス活用術!

    InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が

    知って得するInnoDBセカンダリインデックス活用術!
    masa_matya
    masa_matya 2011/02/24
    セカンダリインデックスの構造について。