3000req / sec と戦う - だるろぐ
ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ
MySQL 5.5をわずか30秒足らずでコンパイルするためのテクニック
べっ・・・別にソースコードなんて自分でコンパイルしないんだからねッ！！などと言わずにまず聞いていただきたい。30秒でMySQLのコンパイルが出来るというこの事実を。最近、細々とビルド時間の短縮に取り組んでいたのだが、正直ここまで爆速になるとは思わなかった。今日はビルド時間短縮のためのテクニックを紹介するので、是非皆さんも参考にして、快適ビルド生活を送って頂きたい！！ 自己ベストは26.262秒マシンの状態や負荷の状況によって多少ビルドにかかる時間は前後してしまうのだが、これまでの自己ベストはなんと26.262秒。平均すると30秒ぐらい。以前は1分を切ることがなかったのだが、今ではなんとその半分でビルドが出来てしまう。これは純粋にmakeをするのにかかった時間であり、cmake（MySQL 5.5以降）やconfigure（MySQL 5.1以前）にかかる時間は除いてある。だがそれでも速い。
SystemTapでMySQLのDisk I/Oを分析する - SH2の日記
実験エントリです。 動機 OracleのStatspack/AWRで取れるファイル単位のDisk I/O情報を、MySQLでも採取したい。これは次に示すようなデータです。 File IO Stats DB/Inst: ORA112/ORA112 Snaps: 6-7 ->Mx Rd Bkt: Max bucket time for single block read ->ordered by Tablespace, File Tablespace Filename ------------------------ ---------------------------------------------------- Av Mx Av Av Rd Rd Av Av Buffer BufWt Reads Reads/s (ms) Bkt Blks/Rd Writes Writes/s Wai
YappoLogs: トランザクションを使用したMySQLのおまとめINSERTはどれくらい速いか
トランザクションを使用したMySQLのおまとめINSERTはどれくらい速いか 元ネタはMySQL のおまとめINSERTはどれくらい速いか - bonar noteです。 トランザクションでまとめてInsertしてからcommitしたほうが速くなるので、元ネタのベンチマークをベースにして試してみました。 環境は macports で入れた mysql 5.1.44 です。 まぁnormalからbulk(100)くらいの差は出てなくても、トランザクション使ってまとめてコミットしても多少速くなっとりますね。 normal と txn の差よりも bulk(100) と bulk(100)_txn の差が小さいのは、 bulk insert で最初から効率的になってるぶん差が少なくなってるという感じでしょうか。 コードは以下の通り。 Posted by Yappo at 2010年03月09日
kur.jp - MySQLでAuto Increment利用による速度低下
kur.jp バイオリンと自転車をこよなく愛するkurのチラシの裏．たまには技術的なことを書いたりするかも知れません． Home About Me Link Webアプリを開発する時に切っても切れない関係にあるのがMySQLなどのRBBMSです．これらをいかに上手に扱うかが，エンジニアリングの面白いところでもあり，難しいところでもあります． 私は今までデータベースでテーブルの設計をするときには，各テーブルに通し番号を記憶するためのフィールドを作成して，Auto Incrementで番号を振っていました． こうしておくと，私が何も考えなくても（Insert文でNULLを指定しておけば），各レコードに連番が付与されるので，非常に便利です． ただ，知ってる人からすると当たり前じゃんと思われるかもしれませんが，Auto Increment属性を指定すると，Insertの速度が遅くなってしまうんです
MySQL 複合インデックスだそうです : にぽたん研究所
livedoor Blog の商売仇かと思われる Seesaa BLOG の中の人「しーさーのパパ」さんが書いている Seesaa開発日記に、「MySQL - 複合インデックスのすすめ」という興味深いエントリがあった。 ちなみに、おいらは今の会社に入社するまでの間、MySQL 自体は自宅で遊ぶ程度にしか使ったことなかったのです。 まともに使って速さにﾋﾞｸｰﾘしたりしていましたが、それでもロクにパフォーマンスチューニングとかしたことがないので、もっと速くしようとする努力を怠ってました。 特にインデックスなんつーものは WHERE 節で使うものに個別に張ればいいんじゃないかと思ってましたし。 でも、WHERE 節と違う ORDER BY が入ると filesort が入ってきて遅くなるんですねぇ。 目からウロコでした。 ということで自宅サーバで実験してみた。 嫌なテーブル名だけど。。。 ちな
さくらのレンタルサーバ
レンタルサーバなら「さくらのレンタルサーバ」！ 月額換算でわずか131円、缶ジュース1本分のお値段で使える格安プランから、ビジネスにも使える多機能＆大容量プランまで、 用途と予算に合わせてプランを選べます。 さらにマルチドメイン対応でメールアドレスも無制限。無料ウイルススキャンや無料電話サポートもあるので安心して ご利用いただける共用レンタルサーバサービスです。
Facebookのサーバーもすごいことになっている件（直近10ヶ月で20,000台のサーバーを追加。ログは毎日25TB。） - shibataismの日記
Googleに比べるととっても地味なPRしかしていないが、実はFacebookのエンジニアリングも結構すごい。CTOのJeff RothschildがUCSDで講演したビデオが見れるので今日がある方は是非見た方が良いと思います。 ビデオ http://cns.ucsd.edu/lecturearchive09.shtml#Roth http://video-jsoe.ucsd.edu/asx/JeffRothschildFacebook.asx 解説記事 http://www.datacenterknowledge.com/archives/2009/10/13/facebook-now-has-30000-servers/ ビデオを見たのが昨日なので、全部覚えていませんが、覚えていることだけでメモを書いておきます。全般的に、非常に素直な講演で、自分たちの良いところも悪いところも素直に言っ
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
データベースを用いたセッションデータ管理について - LukeSilvia’s diary
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
koyachiの日記 - Flickrの中のヒトのLAMP構成プレゼン(Hardware Layouts for LAMP Installations)訳
del.icio.us見てたら面白いファイルがあったので訳しながらはてな記法ワープロでメモったものを公開します。2005/10/18-25に行われたZend/PHP Conference & ExpoにてFlickrのJohn Allspaw氏が発表されたプレゼンの内容のようです。英語読めるヒトは本物のほうをご覧ください。そもそもプレゼンなので長文はほとんどないし、図も入ってるので。天丼に親近感を覚えました。 あと はてな記法ワープロいいですね。ついでにはてな記法なプレゼンツールも是非作ってください！！！ 普通にSQL書いてMySQL使うのは出来るけど負荷とかほとんど考えたことないなーと思って「実践ハイパフォーマンスMySQL」読んでたところでhttp://del.icio.us/tag/flickr+mysqlあたりで見つけました。「実践ハイパフォーマンスMySQL」だと6章から9章辺り
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 倍について
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
京都観光を終えて - mala
「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る：CodeZine