BKCon 2006 - にぽたん研究所
昨日は BKCon 2006 に行ってきた。 BK というのは「一般的にはバッドノウハウの事」なんですが、昨日のは、BKCon と言っても、かつて開催された Bad Knowhow Conference 2004 の続編とかではなく、"B"atara "K"esuma "Con"ference 2006 です。 ※正しくは横浜 Linux ユーザグループ主催の「第 65 回カーネル読書会」のテーマ "mixi.jp: Scaling Out With Open Source" です。 ちなみに、Batara Kesuma さんというのは、株式会社ミクシィの取締役。 mixi の裏側を見せますというか、ちょっと hip な言いかたをすれば "Inside mixi's backend" ってカンジです。 とりあえず、プレゼン内容は YAPC::Asia の時と大凡同じでしたが、プレゼンの持ち
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サーバのハード
「ちょっと待て」 真・MySQLのクエリを最適化する10のTips：CodeZine
Jaslabs: High performance phpで紹介された「MySQLのクエリを最適化する10のTips」に対して、反論している人がいる。ブログ「20bits」のJesse氏だ。彼は「10 Tips for Optimizing MySQL Queries (That don’t suck)」というエントリーで、Jaslabs氏の記事は適切でないとしている。 Jesse氏の経験によれば、SQL最適化で最も重要なことはSQLやDBの基本をしっかりと理解することであり、60％がこれで解決するという。残り35％はDBやクエリの特殊な性質に対する対処であり、最後の5％で発想の転換などを求められる。Jaslabs氏はここにばかり力を入れており、それはまったくもって時間の無駄だと述べている（Jesse氏は「SQL_SMALL_RESULTなんて、生まれてこの方使ったことすらない」とまで言
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
MySQLの最適化
限りなく眠気を誘うPHP Internalsのセッションから逃げる。こっちの 講師はMySQL.comの人。講演慣れしていて、ずっとまともでプロフェッショナルな 感じ。午前中を逃したのが惜しいが、詳しいプレゼン資料は後日公開される らしい。 DELETEのコストはかなり高い 読みだしがすごく多い場合は無効化を示すフィールドを作りUPDATEすべき、 index更新のコストが馬鹿にならないSHOW STATUSの表示結果の解析方法 起動ごとに初期化、全データベースに共通rnd と rnd_next の割合Key_reads : Key_read_requests 、ディスクから読まれた回数：総回数 この割合が1:100より悪くなったら要注意Key_write_requests:Key_writes 総書き込み要求回数：ディスクに書き込ま れた回数 キャッシュの効果などMax_used_con
mMeasure Porject - MySQL監視ソフト
mMeasureとは？ mMeasureは、MySQLの状態を常時測定し、MySQLのチューニングポイントをアドバイスする、MySQL専用モニタリングソフトです。MySQLの主要なサーバー変数やステータスは、時／日／週／月／年の単位でビジュアルにグラフ化され、ブラウザで参照することができます。「クエリーキャッシュ使用率」や「接続数」といった測定値が、あらかじめ設定されたしきい値を超えた場合、MySQLをチューニングするためのアドバイスである「チューニングアドバイス」を表示します。同時に、チューニングアドバイスは「アラートメール」で管理者宛てにメール送信されますので、MySQLのチューニングが必要なタイミングが自動的に分かるという特徴を持っています。 スクリーンショット
MOONGIFT: >> RailsにおけるMySQLのボトルネックを分析する「Palmist」:オープンソースを毎日紹介
Railsは度々遅いということが話題に上がる。Ruby自体の性能もあるだろうが、データベースを富豪的に使っているのにも原因がある。便利であるためについついデータベースを多用していたり、データの取り出しを複雑（都度集計など）にしていないだろうか。 メイン画面 個人的な経験から言えばボトルネックになりがちなのはレンダリングとデータベースだ。このデータベースの問題点を洗い出すのに便利なのが、またしてもRailsアプリケーションだ。 今回紹介するフリーウェアはPalmist、RailsのMySQL実行履歴を見るソフトウェアだ。ソースはGithubで公開されているがライセンスは明記されていなかったので注意していただきたい。 Palmistは他のRailsアプリケーションのログファイルを読み取って、それを解析して表示してくれる。コントローラ、アクション、DBへのCRUDごとにリストアップしてくれる。実
【MySQLウォッチ】第25回 チューニングの指標，ベンチマークのノウハウ：ITpro
誰もが，データベースができるだけ高速で動くことを望む。そのために様々なテクニックを駆使してチューニングを試みる。 チューニングの結果を確認するには，何かしらの指標が必要となる。「体感的に向上した」というのは，まったく当てにならない。正確に性能を把握してこそ，効率的なチューニングが行えるのだ。今回は，ベンチマークについて紹介する。 MySQLのベンチマーク方法 ベンチマークには，２つの方向性がある。一つ目は，決まった処理を通じて，MySQLサーバーの処理速度を計測するものだ。これは，手順が決まっているため，それほど準備は必要ない。また，常に同じ処理を行うので，MySQLサーバーの基本的な処理能力を測るのに適している。 2つ目は，作成したデータベースの処理スピードを計測するものだ。一つ目も重要であるが，結局は，作成したデータベースが高速で動作するかが重要である。さらに，同時アクセス数やデータ量
GIGAZINE、新サーバに移転完了 - GIGAZINE
というわけで、ついに新サーバに移転完了しました。これで負荷が軽減される……はず。予想される負荷に対応するため、カウント数は必要最小限のもののみにとどめました。そのほかにもデータベースの構造を一新しました。これに伴い、トラックバックなどは全リセットされてます、すいません……。 何か不具合などがある場合には臨時用のこちらのメールフォームからご連絡いただければ助かります。 というわけで以下、旧サーバと新サーバの設定などについて。サーバのカスタマイズに興味のある人向け記事第2弾。今度は最も難航したMySQLの設定です。 ◆MySQL メモリをたくさん使えば使うほど高速にレスポンスは返ってくることになるが、GIGAZINEのようにMySQLの中に記事本文しか入っていない場合、つまり非常にコンパクトな場合はメモリをたくさん使ったからと言って反応速度が劇的にアップするわけではない。むしろメモリを極限まで
MySQLのチューニング [データベース] All About
MySQLのチューニング MySQLはスケーラブルなアルゴリズムを使用し、通常の実行時のメモリ消費を小さくしていますが、メモリを多く割り当てると、パフォーマンスが向上します。 mysqld サーバで使用されるデフォルトのバッファサイズは次のコマンドで確認できます。 innodb_force_recovery 0 interactive_timeout 28800 join_buffer_size 131072 key_buffer_size 8388572 long_query_time 10 lower_case_table_names TRUE max_allowed_packet 1048576 max_binlog_cache_size 4294967295 max_binlog_size 1073741824 max_connections 100 max_connect_err
![MySQLのチューニング [データベース] All About](https://cdn-ak-scissors.b.st-hatena.com/image/square/8f530daf3cb408d6b6a0ba6f38ed7ccece36cffc/height=288;version=1;width=512/https%3A%2F%2Fimg.aacdn.jp%2Faa%2Fcommon%2Fogp300_300.png)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
更新があるシステムにはInnoDBを選ぼう。MyISAMを選択するならそれなりの理由が必要。それにInnoDBのパフォーマンスはそんなに悪くないよ。 || パフォーマンスチューニングBlog: インターオフ