All of Percona’s open-source software products, in one place, to download as much or as little as you need.
Multiple column index vs multiple indexes
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
MySQL パフォーマンスチューニング on MySQL Weekly Seminor 2008/06/27 - なんとなく日記
業務で参加ですが，ひとまずログ記録．こんかいから howm でもはてな記法で書いたのでコピペが楽です(ノ∀`)． MySQL パフォーマンスチューニング MySQL は Orcale と同程度の安定性とスケーラビリティがあると評価されている(2005年) パフォーマンスとは？ パフォーマンスの指標 スループット レスポンスタイム・レイテンシ スケーラビリティ 上記のコンビネーション CPU やサーバ環境によって変わるのか，など 指標は平均値だけでみるのではなく，ばらつきを調べるのも重要 キューイング 複数のユーザ・リクエストがある場合に発生 レスポンスタイム = キューイングによる遅延 + 実行時間 飽和するとキューイングによる遅延が増大する 天王山トンネルとかと同じ原理 事前の性能テストでは見えない部分でもある 性尿評価の基準作りが重要 実行時間 : Key to the hotspot
コスいチューニング - フツーな日常
全く本質的でなく効果も小さいものばかりだけど、最後のひと絞りにどうぞ。 Hardware HT無効 今時サーバでNetBurstもないだろうけど、使っているなら切った方が速い。並列実行度が高くなるには違いないが、spin lockとHTは相性がよろしくないし、そもそもNetBurstのHTは速くなる局面が少なすぎる。いっぱいプロセッサが見えるのは気持ちいいが、実効性能を考えると無効の方が速い。 RAID1+0 ブロックサイズは大きめで(256KBとか)にする。"1つのレコードの大きさ ＜＝ RIADのブロックサイズ"である状態だと、RAIDを構成する複数のディスクのうち1個へのリクエストで処理が完結するので具合が良い。逆に"1つのレコードの大きさ ＞ RAIDのブロックサイズ"であると、1レコードの読み出しにも2個のディスクがその処理にかかり切りになってしまう。HDDの毎秒の処理回数は上限
ウノウラボ Unoh Labs: MySQL5からのインデックス結合で１テーブル複数インデックスを使う
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
naoyaのはてなダイアリー - Linuxのページキャッシュ
世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系ＤＢを持っていくと I/O 負荷が激減した件（当たり前だけど） - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
Prepared statementを使うとQuery cacheが効かない - フツーな日常
4.1の日本語化されたマニュアルばかり読んでいたらこの動作への言及が無かったため見落していたが、5.0に対応したオリジナルである英語版にはちゃんと注意が書いてあった。 道理ででnot_cachedばかりが増えていくわけだ。それだけコード側でのprepared statementの利用が徹底されているということは、それはそれで良いのだけど、どうしよう。繰り返し利用しないようなSQLでパラメータも固定のものはprepareしないでいきなり実行するように書き換えてしまうべきか。無論、Injection対策になる部分を無理矢理書き換える必要はないんだけど。 機能として同じような場所で動くものだから協調して動作させるのが難しそうではあるが、本質的に共存不可能なものではないので実装自体が改善してくれると嬉しい。 (追記) よくよく考えると共存はかなり面倒な実装になりそう。そもそもPrepared st
MySQLのパラメータ調整 - フツーな日常
先日和訳したTipsの元のドキュメントを見に行ったら項目毎に整理されていた。パラメータの項目については直接記述するのではなく外部のドキュメントを参照するようになっていたので、そちらも翻訳した。 http://docs.cellblue.nl/easy_mysql_performance_tweaks/ 訳を貼っておいて言うのもなんですが、そんなに目を惹くような事は書いていなかったです。内容はごくごく基本的なことだけ。 以下の項目は影響度の大きい順に並んでいます。 Key Buffer Key bufferはテーブルのインデックスを保持します。多くのメモリとkey bufferはそれだけ速いルックアップを実現できます。必要に応じて調整してください。大容量はもちろんいいことですが、スワップはなんとしても避けて下さい。経験則としてシステムメモリの1/4を割り当てるのが良いとされています。 key
フツーな日常 - MySQLのTips
http://forge.mysql.com/wiki/Top10SQLPerformanceTipsというのがあったので、和訳してみる。 (11/23 追記)id:pekeqさんとsodaさんのコメントを受け一部更新 (4/27 追記と修正)id:hirose31さんの指摘を受け修正。あと元のサイトが構成変更していたので追従 クエリのパフォーマンスに関するTips(データベースのデザインとインデックスについても) EXPLAINを使ってクエリの実行プロファイルを取れ スロークエリログを使え(常に有効にしておけ！) GROUP BYを使っているか使えるなら、DISTINCTを使うな Insertのパフォーマンス バッチ処理によるINSERTとREPLACE INSERTの代りにLOAD DATAを使う LIMIT m,nは案外速くない 2000件以上のレコードに対してORDER BY RA
［MySQLウォッチ］第30回 MySQL 5.0のセキュリティ・ホールとInnoDBの設定
前回からの短い間に，多くのバグフィックスとともに２つのセキュリティフィックスが含まれるMySQL 5.0.25がリリースされている。今回はこれらのセキュリティ・ホールについて解説する。また利用頻度が非常に多いInnoDBのファイル設定に関しても解説する。 MySQL 5.xのセキュリティ・ホール 権限のないユーザーが同名のデータベースを作成できる問題 Linuxなどファイルシステムが大文字と小文字をシビアに識別している環境で，本来作成できないデータベースを作成できてしまうセキュリティ・ホールが発見された。 図1●権限のないユーザーが同様のデータベースを作成できるセキュリティ・ホールの症状(MySQL Bugs: #17647より) 1.$ mysql -u root -p 2.Enter password: 3.mysql> create database sample; 4.mysql>
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う
あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----
【MySQLウォッチ】第8回 MySQLチューニングのテクニック：ITpro
SlowLogの設定 環境設定ファイル(Windowsではmy.ini，Linuxではmy.cnf)に次のような設定を加えるとSlowLogが有効になる。 log-slow-queries SlowLogの有効化(ログファイル名を指定可能) long-query-time=2 SlowLogに記録する処理時間の上限 log-long-format インデックスを使用しないSQL文の記録 long-query-timeパラメータは，SlowLogに記録するしきい値を秒単位で設定する。この場合には，2秒超える処理時間を費やしたSQL文を記録する。また，log-long-formatを指定すると，インデックスを使用しないSQL文もSlowLogに記録する。 SlowLogの確認 SlowLogが動作しているかどうかは，次のコマンドで確認できる。log_slow_queriesがONであれば有効と
phpMyTop
phpMyTop is MySQL Database Monitor Screen Shots can be found here, here, and here. A running example can be found here. Please visit the project files service for the latest release. Project Files The software is currently beta since I haven't tested many different platforms, but it works well in the ones I have tested it on. Please use the support mechanisms on Sourceforge to report bugs and feat
GIGAZINE最大の挑戦、LoadAverage「86」から「3」へ
というわけで、再び負荷を下げる方法を模索した、戦いの記録。 1.MySQLの設定を変更して高速化 2.Zend Optimizer 3の導入 3.ionCube PHP Acceleratorの導入 4.テンプレートの見直しでクエリーを減らす 5.robots.txtでクロールする間隔を制御する 6.MySQLの設定を負荷を低くする設定に変更 7.キャッシュを有効化する 前回解説した「GIGAZINEのLoadAverageを「27」から「2」へ下げた方法」から約3週間後、6月20日（火）の夜、気がつくと負荷の15分平均は「25」をコンスタントに吐き出すようになり、さらに訪問者は急増、ついに6月28日（水）12時45分、負荷対策の効果がほとんど出ないまま、LoadAverage15分平均は「86」に…。 何か対策が根本的に間違っているのだろうか？それとも、もうGIGAZINEサーバのハード
ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」：ITpro
ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」 YAPC::Asia 2006 Tokyo 東京都大田区で開催されているPerl技術者向けカンファレンス「YAPC::Asia 2006 Tokyo」で2006年3月29日，日本最大のソーシャル・ネットワーキング・サイト（SNS）である「mixi」を運営するミクシィのBatara Kesuma（バタラ・ケスマ）取締役最高技術責任者（CTO）が，増え続ける膨大なトラフィックにどのように対処してきたのかについて講演した。カギとなるのは「データベース分割」である。 mixiのシステムはもともとBatara氏が1人で作り上げたものだ。2003年当時，米国でFriendsterなどのSNSがはやっており，同氏が会社（現在のミクシィ，当時はイー・マーキュリー）にSNSを作りたいと提案したところ認められたという。同氏が
Serving Images From A Database | MySQL-dump
Sheeri wrote: So, most of the “I want images in MySQL” conversations are terminated with “Don’t.” People do say this for a reason. Here is the story of your request going through the system: Your systems network buffer fills with a new packet containing a new request from the network card. The system delivers the packet to your Apache, switching from kernel mode into user mode. Apache processes th
１人で稼ぐ日記 | MySQL：１台しかない環境でエセ負荷分散
MySQLのネタ。 １台しかない環境でエセ負荷分散を行う。 MySQLで負荷分散を考えたとき、 １台目にマスターのＤＢサーバー、 ２台目以降をスレーブのＤＢサーバーとして用いる。 マスターは更新系のみのＳＱＬ文を、 スレーブは参照系のみのＳＱＬ文を投げる。 こんな負荷分散を１台のサーバーで行う必要が出てきた。 現在１台でやっていて、ディスクＩＯが追いつかずに捜し求めた結果、下の形で落ち着いた。 １つのテーブルでインデックスを含めたサイズが 30MB〜100MBほどで安定している、という条件があるのですが かなり負荷下がります。 ※上記サイズは搭載メモリサイズによって変わります -------------------------- ■やりかた 負荷が高いテーブルをＡとする １：Ａと同じテーブル構成で、エンジンをMEMORY(he
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Nucleusの使い方
http://tech.blog.klab.org/archives/50277350.html
http://www.yktk.org/diary/20060310.html