MySQLにおける10の最適化設計 - 憂鬱なプログラマの形而上学
MySQLさて、ここでコーヒーブレークして、MySQLの最適化について考えてみたいと思います。MySQLデータベース分散処理では、SQLを複数のサーバーやテーブルへと分散する方法についてご紹介させて頂きましたが、こちらは主に、個々のDBサーバーの最適化について考えてみたいと思います。大きくわけると、MySQLにおいては、以下のことがポイントになるかなと思います。（レプリケーションなどの分散系は他でさんざん触れているのでここでは割愛します）重要だと思う順番に列挙します。１．とにかく分析。できるだけ実際に近いデータでEXPLAINの結果を見たり、slow-queryを分析します。また、CPUの使用状況として、vmstatなどで、できるだけ常にiowaitが0近い状態にします。MySQLは癖が強いので、特に慣れていない人はセオリー通りにいかないことは結構あると思います。ですので、実際の分析を何よ
MySQL table_cacheの設定に関して - shibainu55日記
久しぶりにMySQLネタ。今回はtable_cacheの設定に関するお話。 table_cacheの意味と仕組み まずはじめにtable_cacheの意味をおさらい。table_cacheは1度開かれたテーブルをメモリ上に維持しておき、再利用することでテーブルを開くことによる負荷を低減するためのもの。MySQLではオープンしているテーブル数は「show open tables」コマンドで確認できる。 リファレンスマニュアルでも説明されているが、MySQLでは同じテーブルに対して同時にアクセスするスレッドがあった場合、それぞれが同じテーブルを重複して開く仕様となっており、これによりマルチスレッド環境でのパフォーマンスを向上させている。このことから、MySQLサーバで開かれるテーブル数の最大値は最低でもmax_connectionsと同数であることがわかる。「最低でも」と制限がつくのはjoin
大きめのテーブルにカラムやインデックスを追加する際の注意 - LukeSilvia’s diary
先日大きめ(といっても500万行くらい)のテーブルにインデックス付きのカラムを追加しようとして痛い目にあったので調査。 大きめのテーブルにカラムやインデックスを追加するとどうなるか 今回は単純に、「ALTER TABLE 〜 」で追加しようとしました。追加するカラムは3つで、 varchar(255) インデックスなし varchar(255) ↓のdate 型カラムとマルチカラムインデックスの形式のユニークインデックスあり date インデックスあり SQL を実行し、状況を「SHOW PROCESSLIST」で監視していたら、1つ目のカラム追加で次のような状態に… 最初にState が「copy to tmp table」状態になり、次の状態に遷移するまで1時間かかる 次にState が「Repair with keycache」状態になり、完了までに1時間かかる 次のカラム追加に対す
画像自体をBase64エンコードしてHTML内に埋め込んで高速化するPHPコード例:phpspot開発日誌
Base64 Encoding for Images. 画像自体をBase64エンコードしてHTML内に埋め込んで高速化するPHPコード例。 Googleがインスタントプレビューや画像検索で導入してその読み込み速度に驚いた方も多いかもしれません。 その手法をPHPで実現するコードが掲載されていましたのでご紹介。 PHPでやるにはそんなに難しいわけではなさそう。 <?php $img_src = "image/sample.png"; // 画像ファイルの指定 $imgbinary = fread(fopen($img_src, "r"), filesize($img_src)); // バイナリデータを読み込み $img_str = base64_encode($imgbinary); // base64エンコード echo '<img src="data:image/png;base6
Flashで吹雪のごとき描画を実現するチューニング3策
Flashで吹雪のごとき描画を実現するチューニング3策：速いFlash/ActionScriptチューニング入門（2）（1/4 ページ） Flash/ActionScriptチューニングの基礎知識から実践的テクニックまでを紹介する連載。読みながら試せるオンライン・サンプルもあります。Adobe AIR/Flexにも応用可能です Flash高速化は、ASの知識有無にかかわらず 連載第1回の「Flashを閃光のごとく高速化するための基礎知識」では、実際のチューニング方法を語る前準備として、「どの処理に、どれだけ時間・リソースが割かれているか」、つまり“処理負荷”を調べる具体的な方法を紹介しましたが、あれから1カ月ちょっと経過しました。すっかり季節も変わり始めてしまいました。時がたつのは、速いものです。 今回から、実践的なチューニング手法の解説が始まりますが、プログラムが不要なものから必須なもの
Flashを閃光のごとく高速化するための基礎知識
Flashを閃光のごとく高速化するための基礎知識：速いFlash/ActionScriptチューニング入門（1）（1/2 ページ） Flash/ActionScriptチューニングの基礎知識から実践的テクニックまでを紹介する連載。読みながら試せるオンライン・サンプルもあります。Adobe AIR/Flexにも応用可能です Flashを徹底的に軽く作るための3カ条 本連載では、これから数回にわたり、Flash/ActionScript 3.0（以下、AS3）のチューニングの考え方や方法について解説します。 筆者が初めてFlash/AS3のチューニングと本格的に向き合ったのは、2007年の冬の「サグールテレビ」の開発においてでした。当時、開発チームでは「徹底的に軽く作る」という鉄の目標を掲げており、チューニングのためのさまざまな調査を積み重ねていました。結果、2000年に発売された古いPCなど
Firefoxで長時間ネットを見ているとだんだん重くなってくるのを何とかしたい。 | 教えて君.net
Firefoxの弱点の1つにメモリ消費の大きさが挙げられる。長時間起動したままにしておくとメモリ消費量はどんどん大きくなり、メモリの少ないパソコンではほかの作業ができなくなってしまう。Firefoxを再起動すれば回避できるが、しょっちゅうブラウザを再起動するのは面倒。そこで「AFOM Plus」というアドオンを利用しよう。 指定した間隔ごとにFirefoxのメモリ開放を行ってくれるため、再起動の必要がなくなる。起動したままにしておくと、数百Mバイトものメモリを消費することも珍しくないが、メモリ開放の間隔を短くすれば、常に100Mバイト以内に抑えられるはずだ。 なお、このアドオンは初期設定のままだとFirefox起動時に自動で動作しない。オプション画面からスタートアップ登録しておこう。 「この実験的なアドオンをインストールします」にチェックしてAFOM Plusをインストールし、再起動する
なんかばんざい | MySQLの変な癖、あるいはPostgreSQL使いがMySQLと接するときの心構え
はじめに PostgreSQLのクエリプランナ/クエリオプティマイザは非常に優秀です。ユーザーはただ自分が欲しいデータをSQLで記述し、酷使するカラムに対してインデックスを張ってやればいいだけです（DB自体が酷使されてるなら細かいチューニングは必須です）。MySQLはそれら一連の最適化を人間が担当することになります。 後で詳しく書きますが、たとえば、"SELECT * FROM foo WHERE id IN (1,2)"と"SELECT * FROM foo WHERE id=1 OR id=2"の2つのクエリを、PostgreSQLはまったく同じように処理します。意味が同じなので当然といえば当然です。MySQLもたぶんここまでは同じです。問題は次。 "SELECT * FROM foo WHERE aid=1 OR bid=2 ORDER BY cid DESC LIMIT 10"
Using filesort
去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう？と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル（テンポラリテーブルではない）が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事
9.04 Jaunty の CPU 使用率問題、解決しました - The Spirit of Ubuntu
私の使っている ThinkPad X31 で 9.04 Jaunty Jackalope にアップグレードしたら、Firefox のスクロール（Page Up、Page Down など）がものすごく遅くなってしまった件、解決しました。 端末で top コマンドを使って、様子を見ると、Xorg の CPU 使用率が高いことが分かりました。で、そこらへんで検索して、たどり着いたのが： Bug #363238 in xserver-xorg-video-ati (Ubuntu): “[Mobility] (r100-rv200) very poor Xorg performance - XAA solves this” というページ。ここの Wenzhuo Zhang さんの指摘のとおり、xorg.conf を編集すると改善します。端末で sudo gedit /etc/X11/xorg.con
データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ
データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基本原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 Oracle、SQLServer、MySQLと色々なDBのチューニングをしてきましたが、
Google App Engine + app-engine-patchでCPU時間を短縮する - Pyro Memo
本サーバのログを見ていたらCPU警告だらけになっていたので、チューニングして効果のあったものを記録していく。 参考にしたページGoogle App Engineを高速化する3つのtipshttp://mattn.kaoriya.net/software/lang/python/20080526182049.htm ディスク＜帯域＜CPUの順に制限がキツくなるGoogle App EngineのQuota構成から見るコストパフォーマンスの高いシステム構成http://coreblog.org/ats/now-we-are-free-from-qota-hell Google App Engineのmemcacheを試してみたhttp://taichino.com/programming/487 Google App Engineのmemcache APIがやばすぎるhttp://mattn.
shibu.jp: プロジェクト計画
原著者：Unladen Swallowプロジェクト 原文：http://code.google.com/p/unladen-swallow/wiki/ProjectPlan 原文更新：April 23, 2009 ～Python最適化計画～ 注意: 引用している論文はすべて、 "RelevantPapers"のページからリンクを張っている。中国語版もある ゴール 概要 マイルストーン 2009 Q1 2009 Q2 2009 Q3以降 詳細計画 正規表現 起動時間 テストと測定 パフォーマンス 正確さ 複雑さ リスク コミュニケーション ゴール このプロジェクトではPythonを速くしたいと思っている。また、大きくて安定しているアプリケーションをこのプロジェクト"Unladen Swallow"に切り替えて使用してもらえるようにするのもゴールの一つである。 CPythonと比べて、最低でも
Mozilla Re-Mix: 安全・高速なWebサーフィンを実現する「OpenDNS」
皆さんご存じのように、ブラウザにURLを入力するとそれに該当するIPアドレスを引っ張ってサイトを表示するようになっています。 このような名前解決は、一般的にプロバイダなどから提供されるDNSサーバーが担うものですが、これらは安全性に欠けているとされているものもあれば、一部のサーバーでは名前解決ができないような場合もあります。 また、解決に要する時間はDNSサーバーに左右されることから、処理の速いDNSサーバーを使えばWebサーフィンの高速化に繋がるとも言えます。 「OpenDNS」は、こうした脆弱性を排除し、かつ、高速なブラウジングを実現するために提供されているフリーのDNSサーバーです。 管理者も、遅まきながらこの「OpenDNS」を導入し、Firefoxやその他のブラウザでどのように変化があったのか確認してみました。 「OpenDNS」の導入は、Firefoxになんらかの設定を行うとい
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA
| perlとMysqlでCGI & サーバ管理 漏れ的メモ
TechCrunch | Startup and Technology News
ThinkPad X40のSSD化(5) FileDiskによる擬似RAMディスク / Tips / Cycle of 5th