データベース負荷テストツールまとめ(5) - SH2の日記
というわけで、JPOUG> SET EVENTS 20120721 | Japan Oracle User Groupに参加して発表をしてきました。通常の勉強会と比べて発表者と聴講者の一体感を増すための工夫がなされていて、とても良かったと思います。有限コーヒーかと思ったら無限ビールだったのも驚きです。JPOUGの運営メンバのみなさま、会場を提供してくださった日本オラクルのみなさま、当日お越しいただいたみなさま、どうもありがとうございました。 私のセッションでは、データベース負荷テストツールまとめ(5)と題して過去4回分のまとめと自作ツールの紹介をさせていただきました。JdbcRunnerはOracle Database、MySQLとPostgreSQLの間でTPC-BとTPC-Cの性能比較ができる唯一のオープンソースソフトウェアですので、いろいろ試してみていただければと思います。試した結果
MySQL 5.6におけるsync_binlog=1の改善について＆勉強会のお知らせ - SH2の日記
2012年6月のエントリの続きです。前回は同期レプリケーションによるネットワーク遅延のある環境において、MySQLの性能がどの程度低下するのかということを確認しました。その中でも特にsync_binlogが1に設定されている場合、性能が大きく低下するということが分かりました。参考としてAmazon RDSのマルチAZデプロイメントにおいては、性能と信頼性のトレードオフを考慮した結果、sync_binlogがデフォルトで0に設定されているということを調査しました。 タイトルでネタバレしていますが、MySQLの次期バージョン、MySQL 5.6でこのsync_binlog=1の性能が大きく改善します。前回と同じ負荷テストをMySQL 5.5.25からMySQL 5.6.6-labsに差し替えて行った結果を、以下に示します。 前回のMySQL 5.5.25と異なり、sync_binlog=1にお
うるう秒のあとにMySQLなどのCPU使用率が高騰する件について - SH2の日記
2012年7月1日のうるう秒のあとに、MySQLやJavaなどのCPU使用率が高騰する事象が報告されています。 CPU %user %nice %system %iowait %steal %idle 08時30分01秒 all 0.02 0.00 0.02 0.04 0.00 99.91 08時40分01秒 all 0.02 0.00 0.02 0.08 0.00 99.88 08時50分01秒 all 0.02 0.00 0.02 0.03 0.00 99.92 09時00分01秒 all 0.11 0.00 0.13 0.04 0.00 99.72 09時10分01秒 all 23.02 0.00 29.09 0.11 0.00 47.78 09時20分01秒 all 23.11 0.00 29.08 0.06 0.00 47.75 09時30分01秒 all 22.85 0.00
MySQLのDRBD構成におけるネットワーク遅延の影響について - SH2の日記
今さらですが、Amazon RDSのマルチAZデプロイメントについて調べていました。マルチAZデプロイメントとは、独立した電源、空調、ネットワーク、セキュリティを備えた物理的に異なるロケーションに対して同期レプリケーションを行うことで、データベースの耐障害性を高める機能です。AZはAvailability Zoneの略です。 異なるロケーションに対する同期レプリケーションと聞くと、性能が出ないのではないかという懸念がどうしても出てきます。そこで、どの程度性能が落ちるものなのか検証を行いました。なお、すでに実際のAmazon RDSを利用して検証を行った方がいらっしゃいましたので、今回は手元の環境を利用して、ネットワーク遅延やMySQLパラメータと性能との関連性を確認していきたいと思います。 Amazon RDS MYSQL Performance Benchmarking - Cloud
RHEL 6.3バンドル版MySQL 5.1.61がInnoDB Pluginをサポート - SH2の日記
タイトルで本エントリの内容はほぼ終了となりますが、6月20日にRed Hat Enterprise Linux 6.3がリリースされ、ディストリビューション付属版のMySQL 5.1.61においてようやくInnoDB Pluginが有効化されました。 redhat-release enhancement update for Red Hat Enterprise Linux 6.3 Low: mysql security and enhancement update The InnoDB storage engine is built-in for all architectures. This update adds InnoDB Plugin, the InnoDB storage engine as a plug-in for the 32-bit x86, AMD64, and I
Linux KVM上のWindows XPにおけるMySQLの性能 - SH2の日記
小ネタです。 Visual Studioの英語環境が必要になってLinux KVM上にWindows XPの環境を構築していたのですが、ついでなのでMySQLの性能測定をしてみました。 ホスト CPU：Intel Core i5-2400S (Quad-Core、2.50GHz、Max 3.30GHz) OS：Scientific Linux 6.2 64bit RDBMS：MySQL 5.5.21、innodb_buffer_pool_size=1024M ゲスト1 OS：Scientific Linux 6.2 64bit RDBMS：MySQL 5.5.21、innodb_buffer_pool_size=1024M ゲスト2 OS：Windows XP SP3 32bit DRIVER：Red Hat VirtIO Ethernet Adapter 51.63.103.2200 R
mysqldumpの--order-by-primaryオプションについて - SH2の日記
TIPSです。このようなテーブルがありまして、 CREATE TABLE `link` ( `id1` int(11) NOT NULL DEFAULT '0', `id2` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`id1`,`id2`), KEY `ix1` (`id2`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;データは以下のような感じで、このときは2,900万レコードありました。 +---------+---------+ | id1 | id2 | +---------+---------+ | 5 | 69 | | 5 | 1022 | | 5 | 1487 | … | 1081 | 2021414 | | 1081 | 2087813 | | 1082 | 11 | | 1082 | 225
MySQL 5.0のプロダクトライフサイクルが終了 - SH2の日記
あけましておめでとうございます。今年もよろしくお願いいたします。 新年最初から注意喚起ですが、2011年12月31日をもってMySQL 5.0のプロダクトライフサイクルが終了しました。今後MySQL 5.0に対して新たなバグ修正やセキュリティ修正は提供されませんので、現在MySQL 5.0を利用している方はバージョンアップを計画されることをおすすめいたします。 オラクル社による買収以降、ソフトウェア製品のサポートポリシーは以下のウェブサイトで確認できるようになっています。 Oracle Lifetime Support Policy for Oracle Software MySQL 5.0：2011年12月まで MySQL 5.1：2013年12月まで MySQL 5.5：2015年12月まで (Extended Supportは2018年12月まで) MySQL 5.0のプロダクトライ
INDEX FULL SCANを狙う - MySQL Casual Advent Calendar 2011 - SH2の日記
2011年8月のkazeburoさんのエントリに対する解説記事です。結論から言うとkazeburoさんの案に賛成なのですが、本日はどうしてそうなったのかというところを確認していきたいと思います。本記事はMySQL Casual Advent Calendar 2011の17日目のエントリです。16日目はakira1908jpさんでした。 当時の内容を覚えていない方は、先にkazeburoさんのエントリをご一読ください。また、テストケースがGitHubに公開されていますのでカジュアルに再現試験をすることも可能です。 Covering Index と self-join と MySQL - blog.nomadscafe.jp kazeburo's gist: 1150842 - Gist 問題のSQLをチューニングするには、MySQLがインデックスに対してどのようにアクセスするかという点につ
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
Scientific Linux/CentOS 6.0でMySQL InnoDB Pluginを利用する - SH2の日記
先日CentOS 6.0がリリースされたので、色々試している方も多いと思います。MySQLについて、Scientific Linux/CentOS 6.0では派生元のRed Hat Enterprise Linux 6.0と同様、バージョン5.1.52が採用されています。このディストリビューション付属版のMySQL 5.1.52ですが、残念なことにInnoDB Pluginが無効化されてしまっています。 * Fri Jan 8 2010 Tom Lane <tgl@redhat.com> 5.1.42-4 - Sync with current Fedora build, including: - Update to MySQL 5.1.42, for various fixes described at http://dev.mysql.com/doc/refman/5.1/en/new
MySQLでALTER TABLE文の進捗状況を確認する - SH2の日記
MySQLでテーブルへのカラム追加やテーブルの再編成を行うには、ALTER TABLE文を使用します。MySQLのALTER TABLE文は、変更後の定義にもとづく作業用テーブルを作成し、変更前のテーブルから作業用テーブルへデータをコピーして、最後に二つのテーブルを入れ替えるという仕組みになっています。テーブルへのインデックス追加についても、現在のところ大半のケースで内部的にALTER TABLE文が実行されています。 ALTER TABLE文の怖いところは、処理がもうすぐ終わるのかどうかが分からないところです。テーブルサイズが1GBを超えるあたりから分単位の時間がかかるようになり、100GBともなると本当に終わるのか？と見ていて不安になります。メンテナンス時間が限られている場合は、作業を中断すべきかどうか難しい判断を迫られることもあります。 実は、というほどではありませんが、ALTER
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と同じです。 今回はこのパ
MySQL 5.1.52リリース - SH2の日記
出てます。今回は30件のバグ修正が行われており、そのうちセキュリティに関するものが3件、パーティショニングとレプリケーション双方に関するものが1件、パーティショニングに関するものが2件、レプリケーションに関するものが1件となっています。その他については、InnoDBに関するバグ修正が9件とやや目立ちます。 3件のセキュリティ修正について確認しておきます。運用中の商用システムに対して問題になるものはないと思います。 GeometryCollection型(MultiPoint、MultiCurve、MultiSerface)に対してGeometry型以外の値を割り当てると、サーバがクラッシュすることがありました。今後はサーバがデータ型をチェックし、不正なパラメータを検出した場合は「bad geometry type」として失敗するようになりました。(Bug#55531) あるPrepared
MySQL 5.1.46リリース InnoDB Pluginが正式版に - SH2の日記
出ました。今回は機能追加が1件、バグ修正が55件あります。バグ修正のうちセキュリティに関するものが1件、パーティショニングに関するものが5件、レプリケーションに関するものが7件となっています。 MySQL 5.1.38から本体に付属するようになったInnoDB Pluginですが、バージョンが1.0.7に上がりRCからGA(Generally Available、正式版)となりました。ついに正式リリースです。というわけで何度か繰り返している話題ですが、今回はInnoDB Pluginについて再度おさらいをしておきたいと思います。 InnoDB Pluginの使い方 MySQL 5.1.38以降であればInnoDB Pluginを使うように設定するのは簡単です。/etc/my.cnfに以下の設定を書き加えることでInnoDB Pluginが有効化されます。 ignore-builtin-in
MySQLのスロークエリログから一部を切り出して分析するパッチ - SH2の日記
MySQLのパフォーマンスチューニングに欠かせないスロークエリログですが、このログは特別にlogrotateなどの設定をしない限り一つのファイルに延々と追記される形になっています。先日仕事で3年分ものスロークエリログを見ることがあって大変疲れたので、次回から楽をするためにスロークエリログから一部を切り出して分析するmysqldumpslowのパッチを書いてみました。 オリジナル版のmysqldumpslowはスロークエリログ全体を読み込みます。 $ mysqldumpslow -s t sandbox03-slow.log Reading mysql slow query log from sandbox03-slow.log Count: 2 Time=9223372036854.76s (-1s) Lock=0.00s (0s) Rows=0.0 (0), tpcc[tpcc]@loc
MySQL InnoDBだけで全文検索 - SH2の日記
実験エントリです。 予習してみる 「転置インデックス」というキーワードで検索して、しばらく勉強してみます。 転置インデックス - Wikipedia mixi Engineers’ Blog » 転置インデックスを実装しよう ASCII.jp：悟空、秘剣「転置インデックス」を手に入れる ｜Googleはなぜ的確に探せるのか？ [を] 転置インデックスによる検索システムを作ってみよう！ 転置インデックスで学ぶ検索エンジンの中身アプリ - 睡眠不足？！ うーんなるほど。分かったような分からないような。 作ってみる とりあえず、Twitter4Jを使ってこんなデータを用意しました。ちなみに人選は漢(オトコ)のコンピュータ道: MySQLerのTwitterアカウントまとめ。を参考にさせていただきました。 5707049458,2009-11-14 20:28:34,sakaik,@hbstudy
PHPを組んで作業するのは実力ではないですか？ - SH2の日記
私の職業はWebエンジニアですが 少しPHPがわかるのでルーチン化できるものはPHPを組んでいます。 そうすることによってJavaで1時間かかる作業が1分で終わることがあります。 なので職場では「仕事が早い、仕事ができる」と評価されることがありますが 先日先輩に怒られました。 内容は ・PHPを使うのはずるい ・それは実力ではない ・仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかだ。 ・PHPを組むのはズルとしているのを同じ と。 確かにJavaで行なえば周りの人と同じくらいの速さなので 周りと同じ環境であれば（PHPを組まなければ）仕事が早いとは言えないかもしれません。 しかし業務をどう効率よくして作業をするかを考え実践するのも仕事のうちだと思うのですが 私の考えは間違ってますか？ XSSもチェックするコードを書いたので、ミスはありません。 「PHPを組んだ方が
tpcc-mysqlによるMySQLのベンチマーク - SH2の日記
データベースに対する負荷ツール、ベンチマークツールは世の中にたくさんあるのですが、単一テーブルに対する主キー検索しかしないものなど、CPUクロック勝負の比較的単純なものが多くを占めているようです。そこで本日は、もう少し高度なベンチマーク仕様としてのTPC-Cと、MySQL向けの簡易実装であるtpcc-mysqlをご紹介します。 TPC-Cとは卸売業における注文・支払いなどの処理を擬似的に再現した業務モデルで、TPCという業界団体によって策定されたものです。9種類のテーブルに対する5種類のトランザクションがミックスされており、そのうち注文処理のスループットを測定結果として利用します。公式サイトで仕様書(PDF)が公開されています。 テーブル定義は以下のようになっています。ちなみにこのER図はMySQL Workbenchで出力したものです。 warehouse：倉庫です。倉庫表のレコード数は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
