なぜ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
さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
MySQLのLIMIT句についての質問です。バージョン5.0.22です。…
MySQLのLIMIT句についての質問です。バージョン5.0.22です。 現在DBに1000万件ほどの簡単なデータを入れ色々とテストを行っているのですが、以下のような時、どうしても処理が遅くなってしまいます。これは「LIMIT」の仕様でしょうか。「id」は主キーで「hoge」はテーブル名です。 mysql> SELECT * FROM hoge ORDER BY id DESC LIMIT 9000,10; 10 rows in set (8.30 sec) なお、オフセットの部分が0〜1000くらいでしたら問題ない速度です。 mysql> SELECT * FROM hoge ORDER BY id DESC LIMIT 0,10; 10 rows in set (0.00 sec) mysql> SELECT * FROM hoge ORDER BY id DESC LIMIT 100
livedoor Techブログ : ウェブサービスのサーバ増設の基本（1台構成から仮想化まで）
お疲れ様です、スエヒロです。 先日発売されました、弊社技術陣が執筆した「4Gbpsを超えるWebサービス構築術」、お手に取って頂けたでしょうか？ ウェブサービスの負荷対策、分散技術など、実用的な話が盛りだくさんの本書ですが、本日は実際に稼働しているサービスのサーバスケールアウト方法を、弊社サービス「livedoor ニュース」を例にしてご紹介したいとおもいます。 0. 問題点の把握 2003年オープンしました「livedoor ニュース」ですが、当時はアクセス数、データ量も少なかったため、サーバ1台で運用していました。 静的な画像やcss、javascriptへのリクエストを処理するapache（80ポート）と、動的コンテンツへのリクエストを処理するmodperl組み込みのapache（8080ポート）を切り分け、mod_rewriteでリバースプロキシし、リクエストをながしています。リバ
javascriptを多用したページを早く表示するには « ku
diggにのってた Vitamin Features » Serving JavaScript Fast っていう、Flickrの Cal Henderson というひとが書いてた記事に、最近なんとかなんないのかと思ってたことが書かれていて、すんげー！というわけですぐ試してみたら確かにその通りになって最高でした。 Serving JavaScript Fast ってなんのこと？というかんじだけど、要するにいまどきなWEBページはCSSとかjavascriptとかたくさん使っていて、ページのロードが完了するまで時間がかかるからなんとかしたいよね、という話。 CSSもjavascriptも一度読み込めばキャッシュされるからいいんじゃないの？ たしかに。しかしブラウザは毎回更新されたかどうかを確認しに行って、更新されてない、という答えをもらってから自分が持っているキャッシュを使っているのです
WindowsXP高速化のための設定などを公開してみる - GeekなNooblog
WindowsXPの高速化のための設定を不親切にまとめてみる。 以下の値が存在しない場合は右クリックから新規作成をしてください。 ファイル名を指定して実行 regedit でレジストリエディタを起動 どうやらIoPageLockLimitの設定は意味がないようです。 詳しくはこちら 黒翼猫のコンピュータ日記 2nd Edition:間違いだらけの Windows チューニング その２ (IoPageLockLimit) - Windows 2000 Blog http://w2k.livedoor.biz/archives/880676.html メモリ関連 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Managementを開く カーネルメモリを物理メモリに置く DisablePagi
Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる
Linux は fork で子プロセスを作成した場合、親の仮想メモリ空間の内容を子へコピーする必要があります。しかしまともに全空間をコピーしていたのでは fork のコストが高くなってしまいますし、子が親と同じようなプロセスとして動作し続ける場合は、内容の重複したページが多数できてしまい、効率がよくありません。 そこで、Linux の仮想メモリは、メモリ空間を舐めてコピーするのではなく、はじめは親子でメモリ領域を共有しておいて、書き込みがあった時点で、その書き込みのあったページだけを親子で個別に持つという仕組みでこの問題を回避します。Copy-On-Write (CoW) と呼ばれる戦略です。共有メモリページは、親子それぞれの仮想メモリ空間を同一の物理メモリにマッピングすることで実現されます。より詳しくは コピーオンライト - Wikipedia などを参照してください。 この CoW に
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
Adobe - デベロッパーセンター : Flash Liteのメモリ管理と最適化
メモリを効率よく使用するための最適化 画像、オブジェクトおよび外部データのロードとアンロードを連続して実行しないでください。続けて実行すると、ガベージコレクタサイクルが予定通りに完了されず、アプリケーションはメモリ不足になる可能性があります。例えば、次のように３つのファイルが同じサイズでも、２つのファイルにしかメモリを使用できない場合があります。 ファイル１をロード ファイル１を削除 ファイル２をロード ファイル２を削除 ファイル３をロード ロードが失敗する可能性あり 上のシナリオはお勧めできません。 ファイル１をロード ファイル１を削除 60秒待つ（setintervalを使用） ファイル２をロード ファイル２を削除 ファイル３をロード ロードが成功する可能性が高い この場合は、ガベージコレクションが手順「b」と「d」の間で行われ、メモリが再使用されます。 必要のなくなった変数は削除する
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
インデックスを使った高速化について(ORDERD BYにインデクスが使われない例) - LukeSilvia’s diary
今回は、MySQLの高速化のメモ - @luke_silvia.diaryの方法に従ってクエリの高速化をした際に、MySQLのインデックスについて分かったことを書いておきます。 高速化対象のクエリ 今回高速化したいクエリは、以下のようなもの。 SELECT users.*, students.school, workers.school FROM users LEFT JOIN students ON users.id = students.user_id LEFT JOIN workers ON users.id = workers.user_id WHERE (users.status= 1 AND ((kind = 0 AND students.school = 'test') OR (kind = 1 AND workers.school = 'test'))) ORDER BY
MySQL インデックス - kozy.heteml.jp
テーブル作成時 † mysql> CREATE TABLE index_test_tbl1( -> id INT PRIMARY KEY AUTO_INCREMENT, -> name CHAR(50), -> INDEX idx(id) -> ); ↑ 既存テーブルにインデックスを追加 † CREATE INDEX インデックス名 ON テーブル名(フィールド名); mysql> CREATE TABLE index_test_tbl2( -> id INT PRIMARY KEY AUTO_INCREMENT, -> name CHAR(50) -> ); Query OK, 0 rows affected (0.01 sec) mysql> CREATE INDEX idx ON index_test_tbl2(id); Query OK, 0 rows affected (0.04
MySQLノウハウ
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
【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であれば有効と
Identity Manager, Reconciliation small Test #2. | WebLog about me.
Identity Manager, Reconciliation small Test #2. 前回のテストで、Web ContainerとMySQLを別のマシンに移しても、MySQL側のCPU負荷の高さがボトルネックになり調整機能のパフォーマンスは上がらなかったので、同じ状況で、MySQLのパフォーマンスチューニングを行いました。 MySQLのsupport-filesディレクトリには、my.cnfファイルのテンプレートが何パターンか含まれており、その中の、 my-innodb-heavy-4G.cnf を使用して、再度同じテストを行いました。 このファイルの中の、innodb_buffer_pool_size = 2G（デフォルト8M） とquery_cache_size = 64Mという設定は効果が期待できるパラメータです。 デフォルトのinnodb_buffer_pool_size
bk-mysql
このドキュメントは最近メンテされていない項目が数多くあります。 リンクが切れていたり、現状のmysqlでは直っていたり、変更されている可能性が多々。 その点だけ注意して下さい。 InnoDBへ移行する際に把握しておかなくてはいけない事affected_rowsは英語で「影響を受けた行数」という意味疑似csv形式で出力するソースからの構築時のトラブルなんかよく分からないけどmysqlが重い時mysql_use_result()とmysql_store_result()の違いSHOW TABLE STATUS;my.cnfDBのエンコーディングとVARCHAR(n)の関係リファレンスレプリケーション一行だけmysqldumpするテーブルが破損した時にmysqlをとめずにバックアップを取る場合のパターンなんかよく分からないけどエラーが出た時テーブルの構造を、CREATE TABLEフォーマットで
システム開発の備忘録 | MｙSQL - sleepプロセスが溜まる2
MySQL4.0系を使っているサーバーでまたsleepプロセスが溜まる現象が発生した。 今回は時間が経過していくと一つ一つのプロセスのメモリ使用量が増えていくのが問題。今までそんなに重くなかったのに急にLAが平均10くらいになったよ・・・orz またsleepかよとか思って「MySQL sleep」でぐぐったら2番目にこのブログで書いた記事が出てきたorz その時と同じ方法で解決出来なさそうなので、もうちょっと深いとこまで突っ込んでみた。 sleepプロセスが溜まると、show processlist;を実行した場合やphpMyAdminでプロセスを表示した場合にすぐ分かる。 下記はphpMyAdminでプロセスを表示した例 sleepばっかりです。というかsleepしかありませんorz。 こういう状況が続くとシステムによっては問題が起きます。（今回がまさにそう） じゃあこのsleepって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Yahoo!ニュース」の表示速度が3～5倍に、そのからくりは……：記事の芽
Adobe: Creative, marketing and document management solutions
http://livedocs.adobe.com/flashlite/2_jp/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts_wEcute&file=00000090.html