MySQL 5.1のmysqldumpslowで快速チューニング - SH2の日記
MySQL 5.1のmysqldumpslowを使うとチューニングが楽になる！という話題です。 mysqldumpslowはもともとMySQLに付属しているツールで、スロークエリログを集計してくれるものです。これ自体はMySQL 5.1で特に変わったところはありませんが、スロークエリログ本体の方が機能強化されているため、組み合わせるとなかなか便利になっています。MySQL 5.1におけるスロークエリログの主な機能強化は以下の三点です。 long_query_timeに1秒未満の値を設定できるようになった。 出力先を設定できるようになった。 これらの設定をオンラインで変更できるようになった。 これでどうなるかというと、MySQLの性能分析をしたいと思ったときに、サーバを止めずにその場で mysql> set global slow_query_log = 1; mysql> set glob
スワップサイズをゼロにしてはいけない
先月発売された書籍「Linux-DBシステム構築/運用入門」は、なかなか上々の売れ行きとなっているようです。Amazonではしばらく「1-2ヶ月待ち」の状態が続いてしまっていたのですが、最近になってようやく解消され、容易に入手できるようになっているようです。Amazonの在庫切れ問題がひと段落したところで、これからは書籍のサポート的な情報を書いていくことにします。 まず、本書を購入された皆さまありがとうございました。結構な数の方がBlogやTwitter等で、この本をほめてくださっていることに大変感謝しています。まだ本自体の認知度が低い(存在自体を知らない顧客も多い)ので、普及活動をしつつ、これからも読者の期待に応えられる記事を書いていきたいと思っています。 最初は、よく見かけることの多い「メモリ管理」の話題を取り上げようと思います。第12章では、メモリ管理とスワップ領域に関する解説をして
InnoDBの超高負荷更新処理安定性
最近は沢山CPUコアのある高速なサーバーとか高回転数のHDDが沢山付いたRAIDストレージとか、もの凄く更新系の負荷がかかるベンチマーク(「db_STRESS」 by Dimitriさん)とかがあるので、InnoDBの構成の更新系での様々な限界が見えてきています。 まぁ、現実的にそのような限界を突破する必要のあるシステムがあるかどうかは判りませんが、将来のためにも色々アイデアを加えてXtraDBを作成してきました。今、大幅な変更無しに実装できる範囲のオプションが揃ってきたので高負荷更新系処理のチューニングをXtraDBベースで一旦書き出してみます。 今回もサクサクとポイントだけ。 （IOスレッドを増やす とか、他でも語られている既知のものは省略します。） 今回のチューニングの方針は、 「mutexやrw_lockなどの競合をできるだけ避ける」 ということと 「あまり沢山溜めてはイケナイもの
mysql と drizzle の負荷テストツール「skyload」が凄い！ - kazuhoのメモ置き場
tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
InnoDB Plugin 1.0.4 - InnoDB史上極めて重要なリリース
日本時間の今日、InnoDB Pluginの新バージョン1.0.4がリリースされました。このバージョンでは、「バイナリログを有効にするとグループコミットが効かなくなる問題」が修正されています。ほとんどの環境にとって極めて効果の高い修正です。ほかにもI/Oスレッドの多重化(同様のものがMySQL5.4にも搭載)など効果的な修正が行なわれています。 InnoDB PluginはまだGA(安定版)ではないので、品質面では標準搭載されているInnoDBよりも落ちます。ただしMySQL Enterpriseサブスクリプションを買っている方であれば追加費用無しでInnoDB Pluginのサポートを受けることができるので、お気軽に試してみて頂ければと思います。 グループコミット問題修復の効果のほどは、一目瞭然なので図を見た方が分かりやすいでしょう。下図は、mysqlslapで、複数のコネクションから並
Kazuho@Cybozu Labs: MySQL のクエリ最適化における、もうひとつの検証方法
« メッセージキュー事始め with Q4M | メイン | フレンド・タイムライン処理の原理と実践 » 2008年06月09日 MySQL のクエリ最適化における、もうひとつの検証方法 EXPLAIN を使用して MySQL の SQL を最適化するというのは、良く知られた手法だと思います。しかし、EXPLAIN の返す結果が、かならずしもアテになるわけではありません。たとえば、以下のような EXPLAIN を見て、このクエリが最適かどうか、判断ができるでしょうか。私には分かりません。 mysql> EXPLAIN SELECT message.id,message.user_id,message.body FROM message INNER JOIN mailbox ON message.id=mailbox.message_id WHERE mailbox.user_id=2 OR
Kazuho@Cybozu Labs: MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話
« フレンド・タイムライン処理の原理と実践 | メイン | MySQL の ORDER BY を高速化 » 2008年06月12日 MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話 フレンド・タイムライン処理の原理と実践 の続きです。 先のエントリでは、プルモデルの速度が当初予測していたよりも遅かった (というより SQL レイヤでのオーバーヘッドが大きそうだった) ので、MySQL Internals メーリングリストで質問したりしながら、C++ で直接 InnoDB にアクセスするようなコードを書いてみました。 タイムライン構築速度 タイムライン/秒 SQL そしたら、10倍以上高速に！ ベンチマークを perl ベースのものから mysqlslap に変えたのですが、プッシュモデルの 2/3 の速度が出ています。これなら、データサイズが約 1/10 にな
Kazuho@Cybozu Labs: MySQL の ORDER BY を高速化
« MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話 | メイン | なんとなくリフレクション in C++ » 2008年06月20日 MySQL の ORDER BY を高速化 Pathtraq の拡張にむけて、いろいろ技術的な可能性を調査していると、MySQL の ORDER BY に負荷がかかっていることが分かりました。他にもボトルネックはあるのですが、ここは比較的最適化しやすそうだったので、試しに書いてみました。 mysql51-sort-opt.patch やっていることは、ソートルーチンのベタな最適化です。ORDER BY 句によって悪名高き filesort が実行される場合に、最大30%〜50%ほど高速に動作するようになりました。ただ、自分が書く類いのクエリだと、本質的には top n sort を実装すべきなので、どうしたものかと思っていま
MySQLの管理に役立ちそうな超多機能モニターツール「MONyog」:phpspot開発日誌
MySQL GUI Tools. MySQL Monitor and Manager MySQLの管理に役立ちそうな超多機能モニターツール「MONyog」が結構便利そうです。 WindowsやLinux上で動作するブラウザベースのツールです。 以下に、一部ですがそのフィーチャーについて紹介。 サーバごとのデータ、インデックスサイズが一覧できる データベースごとのサイズ、インデックスサイズなどをグラフで表示 クエリーアナライザー。クエリの統計が見れます。SQLごとの平均、最大実行時間などが分かりやすい どんなクエリが何回呼ばれたかといった統計 接続履歴、トレンド レプリケーションのステータス表示 プロセスリスト ダッシュボード Monyogの更なるスクリーンショットはこちら こちらにMonyogのドキュメントがあるので参考にしてください。 $99 〜のツールになりますが、これだけ多機能で、管
MySQLを診断してチューニングポイントを教えてくれるツール「MySQLTuner」の紹介
MySQLを診断してチューニングポイントを教えてくれるツール「MySQLTuner」 このツールのCentOS5.3へのインストールを実施してみます。 「MySQLTuner」のインストールから、使用方法を紹介します。 このツールはMySQLを診断し、設定値をどのように書き換えたらいいか教えてくれます。 (全部これに頼るというよりは参考程度のようですので、注意が必要です) インストールは簡単。 任意のディレクトリにスクリプトをダウンロードし、実行権限を与えるだけです。 # ./mysqltuner.pl >> MySQLTuner 1.0.0 - Major Hayden <major @mhtx.net> >> Bug reports, feature requests, and downloads at http://mysqltuner.com/ >> Run with '--hel
SDC SQUARE April 2009
昨年12月8日、MySQL5.1がリリースされました。一般提供開始後わずか10日で25万ダウンロードを記録し、デベロッパーの関心がひときわ高い製品です。今回、MySQLのパフォーマンスチューニングのポイントを、サン・マイクロシステムズ株式会社の島拓也さんと奥野幹也さんにうかがいました。（取材：SDC編集局） 編集局：現在のお仕事について教えてください。 奥野さん：私はMySQLの有償版のサポート業務に携わっています。お客様からいただくいろいろな問い合わせ、たとえば、MySQLの使い方や仕様・動作の細かい質問にお答えしています。トラブルシューティングやパフォーマンスチューニングなども含まれます。 島さん：私はx86サーバの販売を担当しています。x86サーバの差別化要因としてMySQLなどの上位のアプリケーションを含めたソリューションのご提案が主な仕事の内容となります。 編集局：サポートチーム
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
Distribution Awareness - MySQL Clusterにおけるスキーマチューニングの定石
MySQL Clusterはデータノードが増えると性能が低下する？？？ そのような噂を聞いたことがないだろうか。この噂は事実を含んでいる面もあるが、殆どの場合は適切にスキーマを設計していないことが原因で起きる。実はMySQL Clusterはその性能を遺憾なく発揮するためにはスキーマの設計が非常に大事なのである。 MySQL Clusterは複数のデータノード（ノードグループ）に対して主キーの値に基づいて行単位で分散されている。主キーに偏りがなければ各データノードに格納される行数は均等になる。つまり、MySQL ClusterはSharding（アプリケーションパーティショニング/Level2分散）を自ら行っていると言えるだろう。 MySQL Clusterでは主キーによるルックアップは、どのデータノードにデータが格納されているかが主キーから分かるため非常に高速である。逆に、主キー以外のキ
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
SSD, XFS, LVM, fsync, write cache, barrier and lost transactions
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
高速SSDの落とし穴。データベースで利用するときはご注意を！
今年はSSDの台頭がめざましい。価格の低下、大容量化、そして高速化、さらには低電力化まで期待できるというからもうHDDの出番はなくなるんじゃないだろうかというぐらいの勢いである。しかしそんなSSDもデータベースで利用する時には気をつけてもらいたい。 MySQL Performance Blogでインテル製SSDを使って検証した結果がレポートされている。 インテル製SSDはめっぽう早い。彼らのテストでは一秒間に5250回もの書き込みが出来たそうだ。しかしそれはライトバックキャッシュが有効になっているときの話であって、ライトバックキャッシュを無効にすると書き込みは秒間1200回まで低下したらしい。（それでも高速だが。） で、このインテル製SSDのライトバックキャッシュはくせ者で、バッテリー等で保護されていない。つまり、ライトバックキャッシュにダーティな（まだディスクへの書き出しが完了していない
さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MyNA Web Site
http://www.mysqlpracticewiki.com/index.php/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8