naoyaのはてなダイアリー - Linuxのページキャッシュ
世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系ＤＢを持っていくと I/O 負荷が激減した件（当たり前だけど） - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
第1回(?) MySQL Beginners Talk開催しました - rkajiyamaの日記
5/29(火)に以前から要望のあった初心者向けとしてのイベントMySQL Beginners Talkを開催しました。ニセ初心者が数多くいたとの情報もありましたが(笑)、ツイートなどでも盛り上がっていたようです。講演者の皆様、スライドうｐおまちしております。 個人的には体調不良で @yokatsuki さんに会場の仕切り全てをお任せしてしまうなど多大なご迷惑をおかけしてしまいました。次回があれば今回の分もぜひがんばりたいと思います。 次回開催はいつだろう？
Oracle Database経験者がMySQLの設計思想を知っていろいろ考える会 - SH2の日記
本日4月4日(水)より、Oracle OpenWorld Tokyo 2012が開催されます。 塩原さんにお誘いいただいて、3日目、4月6日(金)のOracle OpenWorld Unconference presented by JPOUGで発表をさせていただくことになりました。 Oracle OpenWorld の特別セッション「Oracle OpenWorld Unconference presented by JPOUG」 | oracletech.jp 2012年4月6日 Oracle OpenWorld Unconference presented by JPOUG 開催 | Japan Oracle User Group 日時：4月6日(金) 12時30分から 場所：六本木アカデミーヒルズ49 Oracle Technology Networkラウンジ 今回は20分枠という
MySQL InnoDB Deep Talk #1 復習 - SH2の日記
というわけで、InnoDB Deep Talk #1に参加して発表をしてきました。準備のために今月ちょっと睡眠不足でしたが、かなり刺激になったので参加してよかったです。いちいさんを始め運営のみなさま、雨の降るなか参加されたみなさまどうもありがとうございました。 書籍の紹介 当日木村さんと初めてお会いして、今月発売になった書籍「プロになるための データベース技術入門 〜MySQLforWindows困ったときに役立つ開発・運用ガイド」を献本いただきました。どうもありがとうございます！ プロになるための データベース技術入門 ?MySQLforWindows困ったときに役立つ開発・運用ガイド 作者: 木村明治出版社/メーカー: 技術評論社発売日: 2012/03/16メディア: 大型本購入: 2人 クリック: 101回この商品を含むブログ (4件) を見る先に発売された松信さんの本「Webエン
Innodb Double Write
One of very interesting techniques Innodb uses is technique called “doublewrite” It means Innodb will write data twice when it performs table space writes – writes to log files are done only once. Why is Doublewrite is needed? It is needed to archive data safety in case of partial page writes. Innodb does not log full pages to the log files, but uses what is called “physiological” logging which me
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
MySQL memory configuration check tool
mymemcheck �P��{U pt��{U #!/usr/bin/env perl use strict; use warnings; my @GLOBAL_BUFFERS = qw( key_buffer_size innodb_buffer_pool_size innodb_log_buffer_size innodb_additional_mem_pool_size net_buffer_length ); my @THREAD_BUFFERS = qw( sort_buffer_size myisam_sort_buffer_size read_buffer_size join_buffer_size read_rnd_buffer_size ); my @HEAP_LIMIT = qw( innodb_buffer_pool_size key_buffer_size sor
XtraDB / InnoDB internals in drawing
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
MySQL Connector/Jにおける大量INSERTのチューニング - SH2の日記
ピンポイントチューニング講座です。まずは結果から。 このグラフは、以下のテーブルに50,000レコードINSERTしたときの処理時間を示したものです。性能に70倍以上もの差が出ているのはなぜか、見ていきたいと思います。 CREATE TABLE `loadtest` ( `id` int(11) NOT NULL, `data` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 方法1 ベースライン conn = DriverManager.getConnection(JDBC_URL, JDBC_USER, JDBC_PASS); pstmt = conn.prepareStatement("insert into loadtest (id, data) values (?
mysqldumpのオプションについて - OKWAVE
--master-dataオプションの1,2の違いは、 CHANGE MASTER文をそのまま出力する(=1)か、コメントにする(=2)の違いのみです。 オプションをつけない場合はCHANGE MASTER文は出力されません。 マニュアルにもありますが、 --master-dataは--single-transactionが指定されていなければ、 自動的に--lock-all-tablesをオンにする、というオプションでもあり、 実際はこちらのほうが重要であると思います。 --master-dataに関するオプションについては、 InnoDBをお使いなら--master-data=2 --single-transaction、 MyISAMをお使いなら--master-data=2 で基本的に問題ないかと思います。
MySQL 5.1.41リリース - SH2の日記
出ました。今回は機能の追加・変更が4件、バグ修正が62件あります。 MySQL 5.1.38から同梱されるようになったInnoDB Pluginですが、MySQL 5.1.41ではバージョンが1.0.5に上がり、ついにRC(リリース候補版)となりました。再掲になりますがInnoDB PluginはビルトインのInnoDBに比べて以下のような機能強化が施されており、非常に有用性の高いものです。そろそろ利用を検討しても良い時期に入ってきたのではないかと思います。 高速なインデックス作成。従来InnoDBのCREATE INDEXはテーブルの再作成を伴っていました テーブルとインデックスの圧縮 (検証結果その1、その2) INFORMATION_SCHEMAによるロック競合の検出 (検証結果) CPUスケーラビリティの向上 (1.0.3から) バックグラウンドI/Oスレッドの増加 (1.0.4か
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DTraceによるMySQL解析ことはじめ
現場指向のレプリケーション詳説
株式会社コーソル