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 倍について
Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築:TKMR.blog.show
最近、2.0な方々の間でTwitterが話題になってる。で、そのTwitter自体も面白いんだけど、TwitterについてDHHがブログを書いてRailsでの大規模サイト構築が話題になってるのが面白い。 Twitter trouble (Loud Thinking - DHH) まずTwitterの高負荷について言及、Twitterは11,000リクエスト/秒 の高負荷で問題となっているらしい。 そしてスケーラビリティの鍵はDB分割だ、と言っている。Railsは基本一つのDBを見るのでスケーラビリティの問題になる （確かにWebサーバはロードバランサがあればいくらでもスケールするしね、Sessionの共有だけ気を付ければ） ↓ Dr Nic » Magic Multi-Connections: A “facility in Rails to talk to more than o
naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う
あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----
Spread Toolkit で分散ログ (1) - 酒日記 はてな支店
以前 LVS + Ultra Monkey で負荷分散 (設定編) - 酒日記 はてな支店 で書いたように、Apache を LVS で負荷分散したのですが、この際にアクセスログを一つに (時系列を保って) まとめるにはどうすればいいか、ちょっと悩みました。 結局 Apache からパイプ経由で logger コマンドを起動して syslogd でログ取得ホストに飛ばす、ということをしたのですが、いくつか問題が。 ログの先頭に syslogd の日付 (Jan 24 18:33:30 www1 logger: ) が付く → 集計の邪魔 syslog は 1メッセージ 1024 byte までしか記録できないので、尻切れになる行が (稀にだけど) 発生する Linux の syslogd は書き込みの際に頻繁に sync するので、DISK IO が大量に発生して重い 特に最後のは、秒間数
Ywcafe.net
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Healthy Weight Loss Best Penny Stocks Cheap Air Tickets Credit Card Application Top Smart Phones Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information
負荷対策概論 - Y-110's Wiki
最新文章 2018-12-26 17:10▪ 致敬英雄，致敬不朽的精魂 2018-12-26 17:10▪ 四十年来闵行人的文化生活史一幕幕回放 2018-12-26 17:10▪ “笔尖上的童画”——欢图学员作品成果展将在东方网文化活动... 2018-12-26 17:10▪ “金色热线”12月27日将迎来年终特别节目 2018-12-26 17:10▪ 北京市发布持续低温蓝色预警信号 2018-12-26 17:10▪ 北京市网信办推进自媒体账号专项治理关闭11万个 2018-12-26 17:10▪ 有创意的崇明“橘农”让梦想和情怀扎根农场 2018-12-26 17:10▪ 突发！上海地铁3、4号线晚高峰运行延误系人员进入线路 2018-12-26 17:10▪ 中国经济总量将达90万亿关键时刻传递重要信息 2018-12-26 17:10▪ 海底捞："吃出卫生巾"系人为当事顾客
負荷対策概論 - Y-110's Wiki - （ひ）メモ
# トラックバックうてるといいのに。 DB接続のプーリング PHPの*_pconnect系だとhttpdのプロセス分だけ接続が必要で、無駄といえば無駄。 なので、SQL Relayなんかを使うのもアリかと。 ロードバランサ Poundやmod_proxy_balancerもいいけど、Linuxマシンでlvsすればお高いロードバランサ要らずっす。 all in oneならUltra Monkeyがいいけど、中身を理解して弄りたい向きにはkeepalivedがおすすめ。 I/Oパフォーマンス 3wareのハードウエアRAIDカードなんかには、割とでかい（128MBとか）ライトキャッシュがついてるす。これ、ちょー強力。しびれるぐらいI/Oが早くなります。ライトキャッシュ使うときはBBUもお忘れなく。
GIGAZINE - GIGAZINEのLoadAvarageを「27」から「2」へ下げた方法
ここ3日間ぐらい超絶な重さだったのはサーバに物理的トラブルが発生したからではなく、単純に閲覧者数が満員御礼となり、各時間で倍増したためです。LoadAverageはひどいときで15分間の平均値「27.1」程度。瞬間最大風速だともっと高いです……明らかにまずい。 というわけで、Apacheのデフォルト設定で今までは大丈夫だったのですが、ついに高負荷サイト用の設定に変更せざるを得なくなりました。 そのため、実際に行った対処方法は以下の通り。1日30万PV近い動的サイトの高負荷を緩和させる方法として参考になれば幸いです。 まず大前提として、既にDNS逆引きや.htaccessの余計な読み込みなどは停止させていました。下記ページに書いてあることは実行済み。 ＠IT：Apacheパフォーマンス・チューニングの実践（1/2） この状態で負荷が15分平均で「27」になっていたわけです。 また、LoadA
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Web高速化 || パフォーマンスチューニングBlog: インターオフィス