Using filesort
去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう？と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル（テンポラリテーブルではない）が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事
AmazonRDSでslow queryを出力するようにする方法
AmazonRDSは、デフォルトの設定ではslow queryを出力するようになっていない。 また、MySQLが動いているサーバにアクセスすることができないので、slow queryをログファイルに出力したとしてもそれを閲覧する術がない。 RDSでも採用されているMySQL 5.1からは、slow queryをテーブルに保存できるようになったので、それを使う。 方針 ログはテーブル(mysql.slow_log)に出力する。 実行に1秒以上かかったクエリを記録する 100行以上を読み込んだクエリを記録する 普通なら以下のオプションをmy.cnfに設定すればOK。 [mysqld] slow_query_log = ON long_query_time = 1.000 log_output = TABLE min_examined_row_limit=100 RDSの場合は、db-param
GitHub - ahiguti/HandlerSocket-Plugin-for-MySQL: NOTE: THIS REPO IS JUST A COPY. The upstream repo of HandlerSocket has been moved to https://github.com/DeNA/HandlerSocket-Plugin-for-MySQL .
----------------------------------------------------------------------------- HandlerSocket plugin for MySQL Copyright (c) 2010 DeNA Co.,Ltd. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditio
なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1～5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
Amazonクラウドに「キャパシティの限界を超えているのでは？」との疑い
Amazonクラウドの性能低下を経験したユーザーが、Amazonクラウドはデータセンターのキャパシティを超えて利用者と契約しているのではないか？ との疑いを投げかけています。 クラウドは一度使い始めると、現在のところ容易にほかへ乗り換えることはできません。そしてそのクラウドがトラブルに見舞われた場合、利用者自身が問題を解決できる余地はほとんどありません。以下で紹介するのは、実際のトラブルはどうあれ、そうしたクラウドに依存せざるを得ない利用者の立場を浮かび上がらせる話です。 インスタンス性能の低下からネットワークの遅延へ 発端は、Alan Williamson氏による1月12日付けのブログのエントリ「Has Amazon EC2 become over subscribed?」。3年前からAmazonクラウドを利用し続けてきたWilliamson氏は、「Amazonクラウドはまさに限界点を超
JavaScriptの最適化について、code.google.comの記事の適当訳 - それ図解で。・・・tohokuaikiのチラシの裏
GoogleがWeb全体のスピードアップにいよいよ本格的に着手, 一社だけではできないと強調 からリンクのあった、 http://code.google.com/intl/ja/speed/articles/optimizing-javascript.html が日本語かと思ったら日本語じゃなかった・・・・。 いやー、意外とというか文字列については、全然知らんかった。 Closureって便利だし、「おぉ〜俺って使ってるジャン」みたいな気になれるからついつい使っちゃうんだけど、高コストなのね・・・・。反省。 ということで、超適当翻訳。どっかの誰かが書いてるかも。 前おき 著者: Google Chromeのエンジニア Gregory Baker, Software Engineer on GMail & Erik Arvidsson 推奨される経験：JavaScriptの実践的な知識 クライ
MTの再構築時間を10分の1くらいにする黒魔術｜blogs.com
はてブ MTの再構築時間を10分の1くらいにする黒魔術 delicious livedoor クリップ Tumblr Instapaper メールで送信 IT・Web 2009.10.02 0 MTの再構築で時間がかかっている人、全てに福音です。 再構築時間を超絶大幅に短縮するウルトラ必殺技が公開されていました。やったことは、 ストレージエンジンをMyISAMからInnoDBに変更するInnoDBのバッファプールのキャッシュ率を高めるようにmy.cnfの設定 (innodb_buffer_pool_size) を変更する の２つ。結果は... 【テスト環境】 変更前：9時間 変更後：1時間6分！！！！！ 【ネタフルでの適用】 変更前：7時間 変更後：30分！！！！！ すごすぎる！ 改善なんているレベルじゃねー！ もはや革命！ もはや黒魔術！ MTユーザーの方はぜひご検討ください
Six Apart - Movable Type アップグレード 秘話ブログ - :GIZMODO JAPAN編 - :第三話 MT4高速化しよう！講座の巻
2006年からMT3で運営しつづけてきて、今や10,000 超エントリー。そりゃもちろん、再構築にも時間がかかります。だんだん再構築がつらくなってきて、MT4にアップグレードしてついに再構築高速化のテコ入れが必要！ということで、シックス・アパートの柳下先生による、MT4高速化講座が開かれました。 10,000 超エントリーだから、そりゃ再構築にも時間がかかります。 MT4高速しよう！講座中の柳下先生。 MT4.25から追加された、mt-tmpl-testで1エントリーの構築時間を調べてみたところ、0.7秒強。早くもないけど、遅くもないスピードです。10,000件でも7,000秒を超えるわけだから、全てを再構築で2時間を超えることは、単純に考えてもありうるわけです。 一般的にMTの再構築に影響を与えている点として、 1.ページ数 当然ですが、数が多ければ多いほど、再構築に時間がかかります。
Movable Typeをめっちゃ高速化する20の方法。 | Junnama Online
Movable Typeをめっちゃ高速化する20の方法。 公開日 : 2007-07-06 12:41:08 いつかちゃんと書こうと思っていた。 こういうタイトルのEntryをM回以上かくとブログがつまらなくなるらしいのだが、まぁいいや。問題は中身だよ。 ここで言う「高速化」とは、CMSを操作している発信者側、ブログを訪れる訪問者側双方を対象にしている。全てが全てどんな環境でも出来るとは限らないが(特にサーバーに対する権限の問題で出来ない部分も人によってはあるかもしれないが)何しろ20もあるから1つや2つは誰にだって出来るだろう。 環境まわり。 1.ハードウェアのスペックを上げる。 当たり前のことだけど、メモリを増やす、高速なHDDに入れ替える、あるいはサーバー自体を変える。 レンタルサーバーとかだったらプランを変更する。 金かけたくない? とはいえメモリーもHDDも昔と比べたら安いものだ
小野マトペの業務日誌(アニメ制作してない篇) - MySQLで50個のIDからレコードを取得したいときに、プレースホルダで50回叩くのとINで一回で取るの、どっちが速いか。
今日はふぁぼったーのフロントエンドのDB処理まわりをリファクタリングしました。この辺りも、もう1年半も開発・拡張を続けている部分なのでかなり汚くなっており、今後のためにできるだけソースを短くし、保守性の高いコードに書き直すなどの作業です。 そのなかで、以前から気になっていた点があったので、せっかくなので検証してみました。 前提 ふぁぼったーでは、発言をデータベースから取得する際、最初に発言とそのユーザーをSTATUSテーブルとUSERテーブルからSELECTして、そこで得た発言のIDを用いて、右下に出る各発言のふぁぼりユーザーをFAVORITEテーブルとUSERテーブルから別途SELECTしています。二つに分けたのはその方が速かったからですが、今回検証したのは、後半のふぁぼりユーザー取得部分の書き方です。 FAVORITEテーブルから複数の既知のステータスIDのレコードをSELECTしてき
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか 目次 この記事について FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか 背景 概観 詳細 一貫性と原子性 性能 FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか この記事について "How FriendFeed? uses MySQL to store schema-less data" の日本語訳です http://bret.appspot.com/entry/how-friendfeed-uses-mysql CC 2.5 でライセンスされています: http://creativecommons.org/
blog.katsuma.tv
レコードサイズが大きくなってくるとhasOneやbelongsToのアソシエーションでかなり時間を食うときがあります。特に大きな処理をしなくても、ページアクセス時にControllerでdescribe <Table>して、結合した結果を舐めて時間が食われます。 いくらなんでも時間かかりすぎだろ、、と思ってよく調べてみたらCakeでのテーブル間JoinてLeft Joinになってるんですね。クエリ凝視するまで気づかなかった。これ、特に問題なければ内部結合（Inner Join)にするだけでレスポンス速度は大きく変わります。方法はModelでアソシエーション対象Model名のtypeを"INNER"にするだけ。 <?php class User extends AppModel { var $name = 'User'; var $hasOne = array( 'Profile' => a
はてなブックマークのコンテンツの JavaScript を高速化する - IT戦記
はじめに 「新はてなブックマーク」になったということで、とっても便利になったのですが、ブックマーク一覧ページ*1が若干 JavaScript に時間が掛かっているみたいです。 というわけで 調査してみたいと思います。調査して、改善できそうなところは後で纏めて「はてなアイデア」にでも登録しようと思います。 この日記は調査しながら、過程を書いていくつもりです。 準備 まずは、人のサイトの JavaScript を書き換えて試してみるための環境を作ります。 作業用ディレクトリを作る とりあえず、ホームに HatenaJS というディレクトリを作ります。 $ mkdir HatenaJS $ cd HatenaJS CocProxy をダウンロードしてくる 以下から CocProxy というツールをダウンロードしてきます。 http://coderepos.org/share/wiki/CocPr
KOF 2008 の発表資料 - naoyaのはてなダイアリー
KOF 2008 での発表資料「はてな流大規模データ処理」を以下にアップロードしました。 http://bloghackers.net/~naoya/ppt/081108huge_data.ppt 一部参考文献からの引用 (Introduction to Information Retrieval から Vector space model の図、たつをの ChangeLog から転置インデックスの図) があります。この場を借りて感謝。 環境によってはおそらくフォントの表示がいまいちだと思いますが、ご了承ください。 追記 SlideShare にアップロードしました。 081108huge_data.pptView SlideShare presentation or Upload your own. (tags: linux mysql) 追記: メモリはディスクの 150 倍について
Perl スクリプトで遅い場所を特定する方法 - Devel::Profiler / Devel::NYTProf
今仕事で書いてる Sledge アプリがあるのですが、先日負荷テストを行った結果びっくりすることに現行アプリの１０倍遅いことが判明してしまいました・・・orz Sledge フレームワーク自身が重くないことは今までの経験でわかってるのですが、どうにもソースを見直しているだけでは原因が特定できない・・・そんな活躍するのがプロファイラです。プロファイラの御陰で遅いヶ所を特定することができ、無事に想定するパフォーマンスを得ることができました。この内容に関してはまた別エントリにて。 さて、プロファイラを使うとプログラム実行時の各種情報を収集し、性能解析を行うことが可能です。プロファイラについてもう少し詳しくしるには 性能解析 - Wikipedia あたりを読むと良いでしょう。 プロファイラ（英: Profiler）は性能解析ツールであり、プログラム実行時の各種情報を収集する。特に、関数呼び出しの
「はてな流大規模データ処理」を見てきた - もぎゃろぐ
KOF2008：関西オープンソース2008というイベントに来ています。 はてなの伊藤さんの講演があったので、講演メモを公開。 ＃ボクがメモした内容であって、100%言ったとおりに書いてあるわけじゃないので、参考としてご覧ください。 (続き) アジェンダ 大規模なデータ OSのキャッシュ MySQLの運用 大規模データアプリケーションの開発 データの例 はてなブックマークのデータ量：五千万件くらいのデータ量 このデータに対して何百万人がアクセスしてくる状況でどういう作りにするか レコード数 1073万エントリー 3134万エントリー 4143万タグ データサイズ エントリー2.5GB 何の工夫もなく普通にアクセスすると...200秒待っても結果が帰ってこない 大規模データの難しいところ 開発サーバで開発者が作っている時は快適に動いていても、多数の人間がアク
はてなブログ | 無料ブログを作成しよう
賃貸暮らしのわが家の地震対策【揺れから命を守る編】 以前のブログでも記載した、防災の優先順位に基づいて対策を進めています。まだ手をつけられていない部分もありますが、ある程度まとまってきたのでざっくりとご紹介していきます。 優先順位別に改善していっているため、今回は主に地震の揺れ対策がメインになります。…
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHP Application Monitoring and Management .:. New Relic
100万PV／日のmixiアプリモバイルをGoogle App Engineで実装した@gclue_akira氏に直撃インタビュー
TechCrunch | Startup and Technology News
